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1  Introduction 

1.1  Model  Overview 

•  Background 

Groundwars  is  a  weapon  systems  effectiveness  combat  simulation  model  which  provides  the 
results  of  a  land  duel  between  two  forces.  The  model  simulates  battle  at  the  individual  weapon 
system  level  and  employs  Monte  Carlo  probability  theory  as  its  primary  solution  technique. 
The  simulation  is  stochastic  and  event  sequenced. 

Groundwars  is  an  outgrowth  of  the  TANKWARS  model,  version  II,  written  in  the  mid  1980s  by 
Fred  Bunn  of  the  Army  Research  Laboratory  (ARL),  Aberdeen  Proving  Ground,  Maryland.^ 
The  original  model  has  been  modified  by  AMSAA  over  the  years  to  include  numerous  enhance¬ 
ments  and  new  methodologies.  As  the  AMSAA  version  grew  and  evolved,  it  was  renamed 
Groundwars.  The  current  version  of  the  model  is  Groundwars  Version  5.3. 

•  Platforms 

A  total  of  6  different  platform  types  can  be  deployed  between  the  two  forces.  The  user  de¬ 
termines  the  size  of  the  two  forces  (maximum  of  100  total  systems),  the  weapon  mix  and 
performance  data,  the  range  at  which  the  battle  will  begin,  the  attack  angle  distribution  to 
be  used,  the  terrain  statistics  to  be  used,  and  the  atmospheric  conditions.  Each  platform  is 
assigned  one  weapon  type  for  use  throughout  the  battle. 

•  Terrain 

Intervisibility  between  combatants  is  determined  by  statistical  terrain  data.  This  allows  in¬ 
vestigation  of  situations  on  a  general  area  of  terrain.  One  concern  about  results  from  combat 
simulations  is  that  they  are  specific  to  the  area  of  ground  on  which  the  scenario  is  set  and  to 
the  deployment  and  tactics  used  by  both  sides;  the  conclusions  which  are  drawn  from  such 
results  may  or  may  not  be  generally  applicable.  This,  of  course,  can  be  overcome  by  changing 
the  tactics,  deployments,  and  ground;  but  the  time  implications  of  such  a  study  are  generally 
unacceptable.  A  statistical  terrain,  although  developed  from  a  set  (or  sets)  of  defender  lo¬ 
cations  and  attacker  routes  with  accompanying  line-of-sight  (LOS)  arrangements,  is  sampled 
independently  for  LOS  opportunities  during  the  battle  and  for  subsequent  replications,  and 
utimately  provides  a  representation  of  the  terrain’s  LOS  opportunities.  A  statistical  terrain 
model  is  used  to  generate  the  lines  of  sight  which  occur  during  the  battle  from  empirical  data, 
field  trials,  and  other  sources.  Since  data  from  such  sources  are  combined  across  different 
cases  in  which  the  ground,  the  tactics,  and  therefore  deployments  may  all  be  changed,  the 
results  obtained  from  the  simulation  are  not  restricted  to  a  specific  arrangement  of  forces  on 
the  area  of  the  terrain;  thus  the  results  from  Groundwars  are  applicable  to  a  general  type  of 
combat  (e.g.,  the  assault  of  a  well-prepared  position)  and  so  provide  a  basis  for  screening  a 
large  number  of  cases  or  scenarios  prior  to  modeling  a  select  few  in  more  detail  in  a  higher-level 
model. 

Four  terrain  distributions  are  incorporated  into  the  model,  representing  probabilities  of  in¬ 
view  and  out-of-view  LOS  segments  between  individual  defenders  and  groups  of  attackers. 
They  can  be  selected  by  the  user  without  requiring  specific  distributions  to  be  input;  they  are 
Eschenbach,  Hunfeld,  Peine  (Germany)^  and  Al  Mafraq  (SWA)  (Tables  1  and  2).  Eschenbach 
has  choppy  terrain  with  limited  opening  range  and  in-view  lengths.  Hunfeld  has  moderate 
ranges.  Peine  is  flat  and  has  long  opening  range  and  in-view  lengths,  Al  Mafraq  has  even 
longer  in-view  lengths.  Tabk-iop  terrain,  in  which  defenders  and  attackers  always  have  LOS, 
can  also  be  chosen.  The  model  also  allows  the  user  to  input  other  terrain  distributions  if 
desired.  Vehicles  in  overwatch  and  defenders  always  have  line-of-sight  to  one  another. 


^F.  Bunn, “THE  SUSTAINED  COMBAT  MODEL:  TANK  WARS  11,  An  Armored  Combat  Analysis  Program,” 
BRL  Teclmical  Report  ARBRL.TR-09999,  December  1985. 
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Table  1:  Opening  LOS  Range  Distributions 


Opening  LOS  Range  ( 

'Range  at  First  LOS) 

Eschenbach 

Hunfeld 

Range  (M). 

Probability 

Range  (M) 

Probability 

0 

.000 

0 

.000 

1000 

.113 

1000 

.073 

2000 

.444 

2000 

.290 

3000 

.709 

3000 

.619 

4000 

.803 

4000 

.866 

5000 

.926 

5000 

.950 

6000 

.962 

6000 

.985 

7000 

1.000 

7000 

.993 

8000 

.999 

9000 

1.000 

Peine 

Al  Mafraq  I 

Range  (M) 

Probability 

Range  (M) 

Probability 

0 

.000 

0 

.000 

1000 

.000 

500 

.005 

2000 

.055 

1000 

.020 

3000 

.317 

1500 

.025 

4000 

.660 

2000 

.040 

5000 

.836 

2500 

.120 

6000 

.917 

3000 

.220 

7000 

.965 

3500 

.310 

8000 

1.000 

4000 

.390 

4500 

.540 

5000 

1.000 

Table  2:  LOS  Probability  Distributions 


In-LOS  and  Out-of-LOS  Probability  Distribution 

Eschenbach 

Hunfeld 

Range  (M) 

In 

Out 

Range  (M) 

In 

Out 

.000 

0 

100 

wQ 

.117 

100 

.158 

.141 

200 

R  3 

.186 

200 

.239 

300 

.513 

.247 

300 

.379 

.320 

400 

.617 

.308 

400 

.469 

.380 

500 

.703 

.369 

500 

.543 

.441 

600 

.767 

.414 

600 

.589 

.485 

700 

.815 

.458 

700 

.638 

.518 

800 

.853 

.495 

800 

.669 

.544 

900 

.878 

.522 

900 

.705 

.567 

1000 

.898 

.543 

1000 

.740 

.588 

1500 

.954 

.653 

1500 

.871 

.671 

2000 

.981 

.744 

2000 

.950 

.747 

2500 

.994 

.791 

2500 

.979 

.796 

3000 

.997 

.861 

3000 

.993 

.846 

3500 

.999 

.902 

3500 

.997 

.879 

4000 

1.000 

.929 

4000 

.999 

.915 

.  .  4500 

1.000 

.942 

4500 

.999 

.936 

5000 

1.000 

1.000 

5000 

1.000 

1.000 

Peine 

Al  Mafraq 

Range  (M) 

In 

Out 

Range  (M) 

In 

Out 

0 

.000 

0 

.00 

.00 

100 

.118 

.136 

500 

.59 

.61 

200 

.188 

1000 

.77 

.76 

300 

.245 

.274 

1500 

.86 

.84 

400 

.295 

.336 

2000 

.92 

.89 

500 

.340 

.349 

2500 

.96 

.92 

600 

.379 

.417 

3000 

.98 

.95 

700 

.417 

.444 

3500 

1.00 

.97 

800 

.442 

.470 

4000 

1.00 

.98 

900 

.471 

.488 

4500 

1.00 

.99 

1000 

.499 

.507 

5000 

1.00 

1.00 

1500 

.648 

.615 

2000 

.742 

.685 

2500 

.828 

.744 

3000 

.868 

.793 

3500 

.908 

.824 

4000 

.935 

.835 

4500 

.947 

.852 

5000 

1.000 

1.000 
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•  Acquisition 

Given  that  intervisibility  exists  between  two  combatants,  acquisition  may  occur.  An  observer 
may  acquire  a  target  either  by  normal  search  or  by  detection  of  the  target’s  firing  signature. 
Normal  acquisition  is  bEised  on  the  Night  Vision  Electronic  Sensors  Directorate  (NVESD) 
target  detection  routines,  and  is  a  function  of  the  sensor,  the  atmosphere,  the  target,  and 
range.  An  observer  may  also  detect  a  target’s  firing  signature.  Whenever  an  enemy  system 
fires,  there  is  a  probability  that  the  observer  will  detect  it.  If  this  probability  is  met,  the 
observer  begins  engagement  of  the  target  after  a  random  period  of  time  which  is  sampled  from 
a  distribution  generated  from  test  data. 

•  Weapons 

Four  types  of  rounds  can  be  played  in  the  model:  kinetic  energy  (KE),  high  explosive  anti¬ 
tank  (HEAT),  anti-tank  guided  missiles  (ATGM),  and  fire  and  forget  missiles  (FAF).  For  each 
weapon  the  model  requires  system  characteristics  (firing  times,  times  of  flight,  reliability), 
accuracy  data,  and  vulnerability  data. 

•  Target  Engagement 

Three  types  of  target  engagements  can  be  played  in  the  model.  The  first  is  single  target 
engagement  in  which  a  firer  detects  a  target,  begins  engagement  of  the  target,  and  discontinues 
all  other  actions.  The  second  type  allows  the  firer  to  detect  a  target  and  begin  engaging,  and 
to  concurrently  search  for  additional  targets.  Once  the  firer  disengages  the  first  target,  he 
will  select  the  next  target  from  his  list  and  begin  engaging  the  next  target.  The  third  type  of 
engagement  can  only  be  played  with  fire  and  forget  missiles.  In  this  type  of  engagement,  the 
firer  attempts  to  queue  a  number  of  targets,  and  then  fire  a  single  shot  at  each  of  the  queued 
targets  nearly  simultaneously. 

•  Countermeasures 

A  number  of  countermeasures  can  be  simulated.  These  include  smoke  grenades,  laser  warning 
receivers  (LWR),  an  Active  Protection  System  (APS),  and  artillery-delivered  smoke.  When 
an  on-board  grenade  system  detects  an  incoming  round,  it  can  launch  grenades  around  the 
vehicle  and  form  a  cloud  of  smoke  which  may  cause  incoming  missiles  to  abort.  An  APS  can 
sense  an  incoming  round  and  either  destroy,  jam,  or  degrade  an  incoming  projectile.  The  user 
may  control  the  level  of  effectiveness  for  these  self-defense  systems.  Artillery  delivered  smoke 
can  also  be  played  on  the  battlefield  to  degrade  acquisition  capabilities. 

•  Artillery 

Limited  artillery  play  is  also  implemented  in  the  model.  Each  side  can  deploy  one  on-call 
mission  during  a  battle,  and  the  attacking  force  is  given  the  option  to  have  one  preparatory 
artillery  barrage.  For  each  type  of  mission,  there  is  an  associated  probability  of  kill  which  is 
assessed  against  enemy  vehicles.  On-call  artillery  missions  occur  at  random  times  in  the  battle. 

•  Disengagement 

Groundwars  allows  the  user  to  choose  from  two  optional  disengagement  tactics.  A  firer  will 
always  disengage  a  target  after  the  target  is  catastrophically  killed.  One  optional  tactic  is  to 
disengage  a  target  after  hitting  it.  Another  is  to  fire  a  certain  number  of  rounds  at  a  target 
and  then  disengage.  For  these  optional  tactics,  the  model  allows  a  firer  to  return  to  a  serviced 
target  if  he  hasn’t  found  another  target  after  a  period  of  time. 

•  MOEs 

The  primary  measures  of  effectiveness  for  the  simulation  are  loss  exchange  ratio,  mean  casu¬ 
alties,  system  exchange  ratios,  and  average  losses  as  a  function  of  time  in  the  battle.  The 
secondary  measures  include  surviving  force  ratio,  shots,  hits,  and  kills  for  each  weapon-target 
pairing,  and  average  detections  by  each  sensor.  The  amount  of  output  is  directly  controlled  by 
the  user,  and  can  range  from  averages  to  a  detailed  break  down  of  many  facets  of  the  battle. 
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Uses 


Groundwars  can  provide  a  trade-off  analysis  between  major  weapon  system  characteristics  such 
as  fire  control,  vulnerability,  and  accuracy.  It  can  provide  analysis  for  a  number  of  combat 
related  issues  (i.e.  terrain,  atmospheric  conditions,  attack  angles).  The  effects  of  changes 
in  target  acquisition,  target  disengagement  policy,  and  ammunition  storage  can  be  shown 
relatively  quickly  and  easily. 

•  Limitations 

Model  limitations  include  no  modeling  of  suppression,  and  an  emphasis  on  direct-fire  weapon 
systems  only.  Groundwars  also  does  not  play  helicopters  or  mines,  nor  does  it  include  a 
dismounted  infantry  submodel.  In  addition,  only  one  weapon  system  per  platform  is  modelled. 

•  Runtime 

A  major  attribute  of  Groundwars  is  its  quick  set-up  and  run  time  w^hich  allows  for  examination 
of  many  situations  and  conditions.  The  model  provides  a  basis  for  modeling  system  interactions 
and  can  enable  an  analyst  to  obtain  a  good  understanding  of  these  effects  prior  to  large  scale 
combined  arms  modeling. 

1.2  What’s  new  in  Version  5.3 

A  number  of  enhancements  have  been  made  to  Groundwars  since  version  5.0,  to  include  improved 
methodologies,  new  weapon  system  capabilities,  and  some  bug  fixes.  The  following  list  provides  an 
overview  of  these  changes: 


•  Capability  Draw  -  Based  on  the  recommendations  of  the  the  AMSAA/TRAC-WSMR  Joint 
Working  Group  on  Methodologies  in  Combat  Simulation  Models,  the  P-Infinity  Capahiliiy 
Draw  methodology  was  recently  implemented  in  the  Groundwars  model,  replacing  the  older 
Opporiumty  Draw  methodology. 

The  NVESD  (Night  Vision  Electronic  Sensors  Directorate)  target  detection  algorithms  used 
in  Groundwars  calculate  P^Infiniiy  and  T-Bar  (mean  time  to  detect)  based  upon  sensor,  at¬ 
mospheric  conditions,  and  target  characteristics.  P-Infiniiy  can  be  defined  as  the  probability 
of  detection  given  an  infinite  amount  of  time. 

In  Groundwars,  upon  opening  line-of-sight,  acquisition  capability  is  determined  by  drawing  a 
uniform  [0,1]  random  number  and  comparing  it  to  the  calculated  P-Infinity.  If  the  random 
number  is  less  than  P-Infinity,  the  target  can  be  detected  by  the  observer,  and  a  time  to  detect 
is  calculated  based  upon  the  value  of  T-Bar. 

The  Opportunity  Draw  methodology  consisted  of  testing  a  new  random  number  draw  against 
the  value  of  P-Infinity  for  every  opportunity  (i.e.,  new  line-of-sight  opening  between  observer 
and  target).  It  is  felt  that  this  method  misuses  the  P-Infinity  probability  by  repeatedly  drawing 
random  numbers  until,  in  effect,  the  P-Infinity  test  succeeds. 

The  Capability  Draw  consists  of  drawing  a  uniform[0,l]  random  number  at  the  beginning  of  the 
replication  for  each  observer  and  assigning  it  to  that  observer  for  the  duration  of  the  battle. 
The  observer’s  random  number  is  used  for  all  P-Infinity  tests  for  that  observer  for  the  duration 
of  the  battle. 

•  Wide  and  Narrow  Field-of-View  (FOV)  Search  -  Changes  were  implemented  to  simulate 
the  play  of  both  wide  FOV  (WFOV)  and  narrow  FOV  (NFOV)  search;  that  is,  to  simulate  an 
observer  searching  for  targets  in  WFOV,  and,  when  a  target  is  WFOV-acquired,  the  observer 
switching  to  NFOV  and  attempting  to  find  the  target  in  NFOV.  Previously,  Groundwars 
allowed  only  one  FOV  for  search  and  engagement. 


•  Ranging-In  -  Ranging-tn  is  a  process  used  by  gunners  to  adjust  fire  on  the  target.  The 
range-in  process  lowers  accuracy  errors  for  weapon  systems  with  limited  fire  control  since  the 
gunner  must  correct  for  errors  associated  with  target  range  estimation,  system  biases,  etc. 
The  gunner  achieves  more  accurate  fire  by  adjusting  the  aimpoint  in  response  to  the  perceived 
impact  location  of  the  preceding  round,  Groundwars  now  allows  ranging-in  to  be  simulated 
for  burst-fire  weapons. 

•  Javelin  -  Groundwars  can  now  simulate  a  lock-on- before-launch  system  like  Javelin.  See  the 
Weapon  Input  File  descriptions  for  further  information. 

•  Burst-Fire  -  Fixes  to  the  burst  fire  code  now  allow  separate  burst-fire  rounds  to  be  simulated, 
as  well  as  adding  the  capability  to  input  a  different  variable  bias  for  subsequent  burst  delivery 
accuracy.  Also,  ranging-in  capability  has  been  added  as  described  above. 

•  Hunter-Killer  -  Groundwars  allows  simulation  of  the  Hunter-Killer  capability  by  allowing 
a  system  to  detect  up  to  an  input  specified  number  of  targets  concurrently,  simulating  the 
effect  of  a  gunner  engaging  one  target  while  a  commander  continues  to  search  for  another. 
Previously,  Groundwars  only  modeled  one  FOV  capability  for  the  search  and  engagement 
process,  and  the  first  acquired  target  was  passed  immediately  to  the  gunner  for  engagement 
while  the  commander  then  continued  searching.  With  the  new  wide  and  narrow  FOV  search  in 
Groundwars,  Hunter-Killer  is  modeled  by  having  the  commander  acquire  a  target  in  WFOV, 
then  pass  this  information  to  the  gunner,  who  then  proceeds  to  search,  re-acquire,  and  engage 
for  the  target  in  NFOV.  Meanwhile,  the  commander  can  search  in  WFOV  for  another  target. 

•  Communication  -  In  Groundwars,  this  refers  to  inter-vehicular  communication,  i.e.,  com¬ 
munication  among  vehicles  on  the  same  force  for  the  purposes  of  sharing  target  location  in¬ 
formation  (not  situational  awareness).  With  the  new  wide  and  narrow  FOV  capability  in  the 
model,  communication  is  modeled  as  follows:  When  an  observer  acquires  a  target  in  WFOV, 
the  observer  transmits  the  target  location  to  all  other  friendly  systems.  The  original  observer 
and  all  receiving  systems  will  then  attempt  to  acquire  the  target  in  NFOV  before  proceeding 
to  engage.  (Note:  The  only  way  to  govern  the  distribution  of  fire  once  the  information  is 
passed  is  to  increase  or  decrease  the  time  to  wait  (input  variable  described  below)  before  the 
receiving  vehicle  will  react.)  One  set  of  values  per  force  for  the  following  is  input  and  applied 
to  each  unit  in  that  force  for  the  following: 

-  probability  of  receiving  a  transmission  of  target  location, 

-  time  to  wait  before  the  receiving  vehicle  will  conduct  its  field-of-view  search,  and 

-  length  of  time  the  receiving  vehicle  will  search  in  its  field-of-view  before  renewing  normal 
search. 

•  Active  Protection  System  (APS)  -  Degradation  factors  (affecting  lethality  of  incoming 
rounds)  may  now  be  input  by  range  (from  firer  to  target  with  APS)  and  by  vehicle  exposure 
(hull  defilade  or  fully  exposed). 

•  Attack  Angle  Distributions  -  Some  errors  in  the  third  decimal  place  have  been  corrected. 

•  Terrain  -  An  additional  statistical  terrain  is  now  user-selectable  within  the  model.  It  is  Al 
Mafraq,  a  Southwest  Asia  terrain  with  very  long  lines-of-sight. 

•  Rounds  Consumed  Per  Enemy  System  Killed  -  A  new  Measure  of  Effectiveness  has 
been  added  to  Groundw’ars.  Rounds  Consumed  per  Enemy  System  Killed  is  now  included  in 
the  model.  This  MOE  is  a  measure  of  rounds-fired  plus  rounds-stowed-that-are-lost-  when-a- 
system-is-K-Killed  divided  by  enemy-systems-killed.  The  MOE  is  reported  by  platform  type. 

•  Radar  -  A  correction  to  the  radar  acquisition  routine  was  made  which  affects  the  calculation 
of  the  signal-to-noise  ratio. 
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•  Debug  Flags  -  Three  more  debug  flags  (to  total  33)  have  been  added  to  handle  NFOV- 
acquisition,  lock-on^before-launch,  and  Rangc-in  events. 

•  Bug  Fixes  -  A  number  of  rare  but  annoying  run-time  errors  have  been  tracked  down  and  fixed 
involving  the  disengagement,  target  selection,  print  acquisition,  acceleration,  and  deceleration 
routines. 

1.3  Future  Modifications 

As  is  typical  with  computer  simulation  models,  Groundwars  is  an  evolving  entity.  Bugs  are  discov¬ 
ered  and  corrected.  New,  and  hopefully  better,  methodologies  replace  older  ones,  and  enhancements 
are  made  to  simulate  new  technologies  and  weapon  systems.  Modifications  are  also  made  in  order  to 
better  represent  the  combined  arms  battlefield.  Whatever  direction  Groundwars  takes  in  the  future, 
it  remains  our  aim  to  retain  the  current  level  of  resolution  and  methodology  at  which  Groundwars 
models  critical  battlefield  events.  By  trying  to  keep  embedded  engineering  calculations  to  a  mini¬ 
mum,  and  requiring  most  input  data  to  be  in  the  form  of  probabilities,  Groundwars  can  continue  to 
run  quickly,  require  a  modest  amount  of  set-up  time,  and  be  more  easily  modified  to  simulate  new 
weapon  technologies.  Further,  the  use  of  statistical  terrain,  besides  the  inherent  benefit  of  generality, 
keeps  the  model  run-time  short  and  allows  hundreds  of  replications  to  be  run  in  minutes. 

The  following  modifications  to  Groundwars  are  planned  for  implementation  in  early  1995: 

•  Multiple  Weapons  per  Platform  -  This  allows  a  vehicle  to  fire  up  to  three  weapon  types  (e.g., 
firing  a  missile  at  long  range,  a  cannon  round  at  medium  range,  and  a  machine  gun  at  close 
range). 

•  Non-Line-of-Sight  (Phase  I)  -  This  is  to  model  the  firing  of  a  round  when  Line  of  Sight  (LOS) 
is  lost  after  acquisition,  but  before  firing  the  first  round  (e.g.,  STAFF). 


The  following  items  comprise  our  current  list  of  possible  future  modifications  to  Groundwars. 
These  modifications  are  dependent  on  future  requirements  for  Groundwars  and  may  or  may  not  be 
implemented,  depending  on  the  need,  the  time,  and  the  appropriateness. 


•  Multiple  sensors  per  platform 

•  Geometry  (More  explicit  representation  of  terrain  coordinates) 

•  Dismounted  Infantry 

•  Improved  Pinpoint  (Flash  Signature  Target  Acquisition)  methodology 

•  Mines  and  other  barriers 

•  Graphical  output  /  playback 

•  Helicopters 

2  Input  Data  Requirements 


The  program  has  been  released  with  certain  limits  on  the  number  of  units  in  a  battle  (100)  and  the 
number  of  different  vehicle,  weapon  and  sensor  types  which  can  be  played  (6).  These  limits  may  be 
modified  and  the  model  recompiled,  but  some  additional  modifications  may  be  needed  within  the 
program  to  achieve  this. 
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Groundwars  requires  a  number  of  input  files.  There  is  a  game  control  file  in  which  the  user 
determines  the  scenario,  the  terrain,  and  the  level  of  output  desired.  This  file  also  determines  the 
attack  angle  distribution,  the  visibility  conditions,  etc. 

For  each  army  there  is  a  unit  deployment  file  in  which  the  number  of  units,  the  starting 
locations  of  the  units,  and  the  function  of  the  units  in  the  battle  is  set.  An  army  information  file 
describes  force  characteristics  such  as  disengagement  tactic,  artillery  lethality,  and  decoys  for  each 
army.  Each  side  has  a  file  which  describes  its  vehicles,  one  for  its  weapons,  and  one  for  its  sensors. 
For  each  weapon  system  there  is  an  accuracy  file,  and  for  each  weapon-target  pair  there  may  be  a 
vulnerability  file.  If  artillery  delivered  smoke  or  other  obscurants  are  to  be  played,  a  file  is  required 
to  characterize  the  periods  and  levels  of  obscuration.  If  fratricide  and  combat  identification  (CID) 
are  played,  additional  files  are  required  which  describe  engagement  rules  and  CID  effectiveness. 

All  files  except  the  Individual  Unit  Action  (lUA)  vulnerability  files  are  free  formatted.  Com¬ 
ment  lines  may  be  added  to  the  TOP  of  any  input  files  by  starting  the  line  with  an  asterisk  (*). 
Any  lines  shown  in  the  documentation  are  there  for  clarity  and  the  program  expects  them  to  be 
there.  They  may  be  changed,  but  cannot  be  deleted.  Data  which  are  entered  as  character  strings 
can  be  a  maximum  of  seven  letters  long  and  can  include  capital  or  small  letters  (longer  strings  will 
be  truncated  to  seven  letters).  All  times  which  are  entered  into  the  data  files  are  in  seconds,  and  all 
linear  measurements  (dimensions,  speed,  etc.)  are  in  meters. 

The  program  searches  for  all  of  its  input  files  in  the  current  working  directory.  All  input  files 
which  are  needed  for  the  battle  must  be  assembled  into  the  current  directory  prior  to  execution  of 
the  program.  The  program  requires  input  files  with  specific  names.  These  names  will  be  explained 
in  the  specific  input  sections. 


2.1  Game  File 

This  file  defines  the  scenario  to  be  played  and  contiols  the  level  of  output.  The  file  must  be  named 
game  in  the  current  w^orking  directory  for  the  program  to  read  it.  The  general  structure  of  the  file 
is  shown  in  Table  3.  Tables  4  through  6  list  Game  File  input  variable  definitions.  Table  8  shows  a 
sample  game  file.  Table  9  lists  output  control  flag  options.  Table  10  shows  the  input  structure  of 
user  defined  terrain  input  data. 


Table  3:  Game  File 


Line 

0 

**  Comment  Line(s) 

1 

Scenario:  RED  Attack,  BLUE  Attack,  STATIONARY  Engagement 

2 

Terrain:  Eschenbach,  Hunfeld,  Peine,  A1  Mafraq,  Table-top,  Other 

3 

Attack  Angle  Distribution:  Cardioid,  Frontal,  CV-CPOA,  Close  Combat 

4 

Atmospheric  Visibility  Range,  Optical  Attenuation,  Thermal  Attenuation 

5 

Output  Control  Flags  (7) 

6 

Program  Debug  Flags  (33) 

7 

Range  Increment  for  Input 

8 

Maximum  Battle  Time  in  Seconds 

9 

Increments  for  Output  Tables:  Time,  Range 

10 

Maximum  Number  of  Replications,  Initial  Random  Seed 

11 

Pinpoint  Restriction  Flag 

12 

Statistical  Confidence  Level,  Relative  Width 

13+ 

User  specified  terrain  distributions  (only  input  if  “Other”  on  line  2) 
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Table  4;  Game  File  Input  Definitions 


Line 

Variable 

Definition 

1 

Scenario 

Type  of  Engagement  (Character  String)  [RED  Attack,  BLUE  Attack,  STA¬ 
TIONARY  Engagement] 

2 

Terrain 

Statistical  terrain  distribution  for  the  model  to  use  to  generate  line-of-sight 
during  play  [Eschenbach^  Hunfeld,  Peine,  Al  Mafraq,  Table-iop,  Other].  If 
“Other”  is  selected,  the  user  must  input  additional  lines  describing  the  user- 
specified  terrain.  See  line  13-}-  description  below  for  further  information. 
(Character  String) 

3 

Attack  Angle  Dist 

Identification  of  w^hat  distribution  is  to  be  used  when  sampling  to  deter¬ 
mine  the  angle  of  impact  in  the  horizontal  plane  for  an  incoming  round 
(Character  String).  See  Table  7  for  a  list  of  the  available  distributions. 
[Cardioid,  Frontal,  CV-CPOA,  Close  Combat]. 

4 

Vis  Range 

Atmospheric  Visibility  Range  in  km.  Used  along  w’ith  other  input  to  deter¬ 
mine  target  acquisition  capabilities  during  the  battle. 

Optical  Atten 

The  corresponding  atmospheric  attenuation  coefficient  for  optical  transmis¬ 
sion. 

Thermal  Atten 

The  corresponding  atmospheric  attenuation  coefficient  for  thermal  trans¬ 
mission. 

5 

OFIags 

Output  Control  Flags.  These  seven  integers  determine  the  detail  and 
amount  of  output  generated  for  a  battle.  If  all  flags  are  set  to  zero,  only  the 
summary  statistics  representing  the  averages  of  the  replications  run  for  the 
case  will  be  listed.  The  output  generated  by  setting  flags  to  non-zero  values 
are  shown  in  table  9.  For  example,  setting  flag  two  to  the  value  of  one  or 
two  causes  an  echo  of  some  of  the  weapon  system  characteristics  inputs  to 
help  the  user  check  for  input  errors.  Analysis  of  acquisition  capabilities 
can  be  aided  by  listing  acquisition  probabilities  and  time  estimates  as  a 
function  of  range  for  each  sensor/target  pairing  (flag  three). 

6 

DFlags 

Program  Debug  Flags.  This  line  contains  33  flags  which  enable  printing 
of  many  variable  values  as  the  model  executes.  These  are  intended  for 
debugging  purposes.  They  should  not  be  set  greater  than  zero  for  more 
than  one  replication,  as  they  produce  a  lot  of  output. 

9 


Table  5:  Gaune  File  Input  Definitions  -  Continued  (1) 


IBB9 

Variable 

Definition 

1 

Rginc-In 

Range  Increment  for  Input.  When  range- depen  dent  data  are  read  in  other 
input  files,  the  ranges  used  must  be  in  increments  of  this  variable.  Examples 
are  vulnerability  data,  accuracy,  and  firing  times.  Increment  is  in  meters. 

8 

Max  Time 

Maximum  Battle  Time  in  Seconds.  This  time  will  be  used  to  end  the  battle 
unless  all  combatants  on  one  side  are  dead  or  non-functioning.  Note:  When 
playing  an  attack/defense  scenario,  do  not  input  a  maximum  battle  time 
which  allows  the  attacking  force  to  over  run  the  defenders,  and  continue 
past  them.  This  will  probably  cause  a  runtime  error.  (The  attacking  force’s 
movement  rate  is  input  in  the  vehicle  file.  Each  army’s  initial  deployment 
location  is  input  in  their  respective  unit  deployment  files.) 

9 

Time  Inc 

Increments  for  Output  Tables  by  Time.  This  variable  allows  the  user  to 
control  the  output  of  certain  measures  of  effectiveness  which  are  recorded 
and  reported  as  a  function  of  time  (sec).  Included  MOEs  are  average  RED 
and  BLUE  losses  and  exchange  ratio. 

Rginc-Out 

Increments  for  Output  Tables  by  Range.  This  variable  allows  the  user  to 
control  the  output  of  certain  measures  of  effectiveness  which  are  recorded 
and  reported  as  a  fuction  of  range  (in  meters).  Included  MOEs  are  acqui¬ 
sitions,  shots,  hits,  and  kills. 

10 

Max  Reps 

Maximum  Number  of  Replications.  Since  Groundwars  is  a  monte  carlo 
model,  a  number  of  replications  must  be  run  to  achieve  a  certain  level 
of  confidence  in  the  output  (see  line  12  below).  Typically,  300  to  500 
replications  are  sufficient  for  most  studies,  depending  on  the  total  number 
of  combatants  played.  This  input  number  of  replications  will  be  used  only 
if  the  desired  level  of  statistical  confidence  has  not  been  reached  by  this 
point  (see  line  12  below). 

Ran  Seed 

Initial  Random  Seed.  An  integer  is  needed  for  use  as  a  seed  for  Groundwars’ 
random  number  generator.  For  example,  12345678. 
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Table  6:  Game  File  Input  Definitions  •  Continued  (2) 


Line 

Variable 

Definition 

11 

Pinp  RFlag 

Pinpoint  Restriction  Flag.  The  ability  of  an  observer  to  detect  a  target’s 
firing  signature  (pinpoint)  can  be  restricted  by  this  input.  Setting  this  flag 
to  zero  allows  observers  to  detect  firing  signatures  regardless  of  their  ability 
to  detect  the  same  target  (given  its  range,  etc.)  by  normal  search.  Setting 
the  flag  to  a  value  of  one  restricts  the  observers’  ability  to  pinpoint  a  target 
to  those  situations  in  which  the  calculated  value  of  P-Infinity  (based  on  the 
sensor,  target,  atmosphere,  and  current  range)  is  greater  than  zero. 

12 

Conf  Level 

Statistical  Confidence  Level.  This  is  for  the  desired  confidence  level  for  the 
output  RED  and  BLUE  dead,  and  Exchange  Ratio,  Along  with  the  next  in¬ 
put,  relative  width,  they  are  used  to  terminate  the  simulation  if  the  desired 
level  of  confidence  has  been  reached.  The  model  records  the  results  from 
each  of  the  replications  and  calculates  the  mean  and  standard  deviation  for 
all  preceding  replications.  If  the  results  meet  the  statistical  criteria  which 
the  user  sets  for  all  three  of  the  above  measures  of  effectiveness  the  model 
terminates  execution.  The  user  specifies  the  level  of  confidence  (80. ,90. ,95., 
98., or  99.)  and  the  relative  width  (see  below). 

Relative  Width 

Specifies  the  desired  coverage  of  the  calculated  mean  with  respect  to  the 
true  mean  of  the  distribution.  Usually  between  .05  and  .15.  For  example, 
if  the  user  specified  95  percent  confidence  and  a  .05  for  the  relative  width, 
then  one  can  be  95  percent  confident  that  the  true  mean  of  the  distribution 
is  within  5  percent  of  the  displayed  mean. 

13-+ 

[User  Terr  Dist] 

Only  input  if  “Other”  is  specified  on  line  2.  If  a  user  defined  terrain  is  being 
used,  an  additional  section  to  the  file  must  be  input  here.  For  intervisibil¬ 
ity,  the  model  first  finds  the  range  at  which  line  of  sight  first  opens;  this 
occurrence  is  characterized  by  the  first  opening  range  distribution.  Once 
the  initial  opening  range  is  found,  the  model  draws  alternating  in  and  out 
of  view  segments  of  varying  lengths.  The  lengths  of  these  segments  are 
drawn  from  two  additional  distributions.  The  format  for  entering  the  three 
distributions,  first  opening  range,  in-view  segment  lengths,  and  out  of  view 
segment  lengths,  is  shown  in  Table  10.  Note  the  probability  distributions 
are  cumulative  and  the  values  for  the  longest  ranges  must  be  1.0. 
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Table  7:  Attack  Angle  Distributions 


Cardioid 

Frontal 

Close  Combat 

CV-CPOA 

Angle 

Prob 

Angle 

Angle 

Prob 

0. 

.0000 

■Kiiil 

25. 

.1365 

15. 

.2925 

15. 

A 1 

15. 

.1815 

45. 

.2370 

45. 

45. 

B  |Sn 

45. 

75. 

.3620 

75. 

75. 

HrSTn 

75. 

Bwjil 

105. 

.4460 

105. 

105. 

105. 

.4525 

135. 

.4880 

255. 

135. 

165. 

.5000 

.5075 

165. 

165. 

.4945 

180. 

.5000 

315. 

180. 

195. 

.5000 

345. 

195. 

195. 

225. 

.5120 

225. 

.5190 

255. 

.5540 

255. 

255. 

.5475 

285. 

.6380 

285. 

285. 

315. 

.7630 

315. 

315. 

.6960 

335. 

.8635 

345. 

345. 

mm 

360. 

1.0000 

360. 

Bi 

Table  8:  Game  File  Sample 


**  Sample  Game  File 
red  attack 

♦scenario  description 

Peine 

♦terrain  specification 

cv-cpoa 

♦attack  distribution 

7.0  .69  .42 

♦visibility  range,  optical,  and  thermal  attenuations 

1  0  2  0  0  1  0 

♦output  control  flags 

33*0 

♦debug  flags 

500. 

♦range  increment  for  data  input 

852. 

♦max  battle  time 

60.  500. 

♦output  increments:  time,  range 

500  11111111 

♦nreps,  initial  seed 

0 

♦pinpoint  restriction:  0=none,  l^pinfinity 

95.  .05 

♦conf  level,  rel  width 
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Table  9:  Output  Control  Flags 


Flag 

Input 

Description 

1 

1 

Normal  output  plus  a  one  line  summary  of  each  replication 

2 

Normal  output  plus  a  detailed  account  of  all  critical  events  in  the  battle 
(Do  not  run  more  than  a  few  replications) 

1 

Output  of  weapon  system  characteristics  (round  type,  firing  times,  reliabil¬ 
ity,  etc.) 

2 

Sample  of  vulnerability  data  for  each  weapon/target  pairing 

3 

1 

Output  of  acquisition  estimates  for  each  sensor 

2 

Output  of  acquisition  estimates  for  every  change  in  atmospherics  caused  by 
artillery  smoke 

4 

1 

Trace  entry  and  exit  from  important  routines  (Do  not  run  for  more  than  a 
few  replications) 

5 

1 

Output  all  events  as  they  are  scheduled  and  canceled  (Do  not  run  for  more 
than  a  few  replications) 

6 

1 

Output  of  killer-victim  scoreboards  by  range 

7 

1 

Output  of  distribution  of  shots  for  each  weapon  type 

Table  10:  User  Defined  Terrain  Statistics  Input 


Line 

1 

Number 

Nximber 

of  points  in  In-View  and  Out-of-View  distributions, 
of  points  in  Opening  Range  distribution 

2 

3 

Rangel 

Range2 

Probability!  (of  Opening  Range  at  Rangel) 
Probability2  (of  Opening  Range  at  Range2) 

n 

RangeN 

1.0 

n+1 

n“h2 

Rangel 

Range2 

Probability!  (In-View)  Probability!  (Out-of-View) 
Probability2  (In-View)  Probability2  (Out-of-View) 

n-fm 

RangeM 

1.0  1.0 
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2.2  Unit  Deployment  File 


The  force  size,  the  location,  the  exposure  and  the  type  of  combatants  for  each  army  are  defined 
in  the  unit  deployment  file.  Within  this  file  are  specified  the  names  of  the  vehicles,  weapons,  and 
sensors  which  will  be  used  in  the  simulation.  These  names  are  important,  as  they  will  be  used 
throughout  the  other  data  files.  Each  army  has  a  unit  deployment  file  which  must  be  named  hunii 
for  BLUE  and  runii  for  RED.  The  structure  of  these  files  is  shown  in  Table  11.  Table  12  shows  the 
input  variable  definitions  for  it. 


Table  11:  Unit  Deployment  File 


Line 

0 

Comment  Line(s) 

1 

* 

unit  number 

type  of 

exposure 

location 

vehicle 

veapon 

sensor 

2 

♦ 

naine 

combatant 

name 

name 

name 

3 

COMPANY  2 

Defender 

HD 

4000. 

BRAD 

T0W2 

ANTAS 

4 

RECON  4 

Defender 

HD 

4500. 

EMMWV 

COAX 

ANTAS 

5+ 

' 

* 
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Table  12:  Unit  Deployment  File  Input  Definitions 


Variable 

Definition 

Unit  Name 

Used  to  distinguish  combatants  of  this  unit  type  from  those  in  other  unit  types. 

A  unit  type  is  defined  by  combatant  type,  exposure,  initial  location,  vehicle  type, 
weapon  type,  and  sensor  type.  All  output  will  be  shown  in  reference  to  these  unit 
names. 

Number 

The  number  of  combatants  of  this  unit  type. 

Tcombat 

Type  of  combatant.  [Defender,  Attacker,  or  Overwatch] 

Exposure 

The  exposure  of  the  units  is  either  hull  defilade  (HD)  or  fully  exposed  (FE).  Both 
defending  and  overwatch  units  are  stationary,  and  can  be  either  HD  or  FE.  Defend¬ 
ers  will  begin  firing  upon  detection  whereas  units  in  overwatch  can  deploy  the  tactic 
that  they  will  not  engage  until  an  enemy  vehicle  has  begun  the  battle  (overwatch 
tactic  is  set  in  the  army  file).  Attackers  are  moving,  and  should  be  fully  exposed. 
For  a  stationary  engagement  both  forces  are  stationary;  one  force  will  consist  of  all 
defenders,  and  the  other  will  be  all  overwatch.  For  an  attack  scenario,  the  attacking 
force  will  consist  of  attacker  units  and  overwatch  units  against  defending  units. 

Location 

This  is  the  location  of  these  units  on  the  battlefield  in  meters.  Because  of  the 
way  the  model  keeps  track  of  the  units,  attackers  move  in  the  positive  direction. 
For  example,  if  the  battle  is  a  BLUE  attack  and  the  initial  battle  range  is  4000 
meters,  the  RED  defense  would  be  placed  at  4000.  and  the  BLUE  attackers  would 
be  started  at  0  meters.  Overwatch  units  can  be  placed  at  any  range. 

Vehicle  Name 

A  seven-character  or  less  vehicle  type  identification.  These  names  will  be  used  in 
the  other  input  files  and  the  names  must  match.  The  different  vehicles,  weapons, 
and  sensors  can  be  mixed  between  the  different  units. 

Weapon  Name 

A  seven-character  or  less  weapon  type  identification.  These  names  will  be  used  in 
the  other  input  files  and  the  names  must  match.  The  different  vehicles,  weapons, 
and  sensors  can  be  mixed  between  the  different  units. 

Sensor  Name 

A  seven-character  or  less  sensor  type  identification.  These  names  will  be  used  in 
the  other  input  files  and  the  names  must  match.  The  different  vehicles,  weapons, 
and  sensors  can  be  mixed  between  the  different  units. 

2.3  Vehicle  File 


The  vehicle  files  contain  data  which  describe  system  platforms.  The  file  describes  such  characteristics 
as  the  physical  size  and  the  speed  of  the  vehicles.  For  each  army  there  is  one  vehicle  file  which 
contains  a  subsection  for  each  vehicle  in  that  army.  The  BLUE  vehicle  file  is  called  bveh^  and  the 
RED  file  is  called  rveh.  Each  subsection  has  the  same  structure,  and  the  subsections  can  be  entered 
in  the  file  in  any  order.  The  vehicle  names  used  in  this  file  must  agree  with  those  specified  in  the 
unit  deployment  file. 

Table  13  shows  the  structure  of  the  vehicle  subsection.  Each  subsection  can  begin  with  de¬ 
scription  or  comment  lines  to  denote  what  this  vehicle  is  (e.g.,  ***  MlAl  ***  or  ***  MlAl  with 
20  perctni  signature  reduction).  The  lines  in  the  sample  which  begin  with  must  remain  in  the 
file  or  an  error  will  result.  They  are  included  to  help  the  user  when  entering  the  data.  Tables  14 
through  19  list  the  vehicle  file  input  variable  definitions. 
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Table  13:  Vehicle  File 


Line 

0 

**  Comment  Line(s) 

1 

Vehicle  Name 

2 

— Turret  dimensions:  Height  1/2  Width  Length 

:  Front  Back 

3 

x.x  x.z 

x.x  x.x 

4 

— Hull  dimensions:  Height  1/2  Width  Length 

:  Front  Back 

5 

x.x  x.x 

x.x  x.x 

6 

— Tgt  Acq  data:  Hull  Defilade  Fully  Exposed 

7 

x.x  x.x 

♦Optical  Contrast 

8 

x.x  x.x 

♦Thermal  Contrast 

9 

x.x  x.x 

♦Characteristic  Dimension 

10 

x.x  x.x 

♦Radar  Cross  Section 

11 

— Movement:  max  speed  acceleration  deceleration  Pause-in^Def 

12 

x.x  x.x  x.x 

X 

13 

— Times  to  Leave  the  Battle:  Jockey  When  Empty  When  F-Killed 

14 

XX. X  XX. X 

XXX.  X 

15 

— Active  Protection:  Arc  of  Protection  Number  of  Launches 

16 

XX  .X 

XX 

17 

— Num  Rajiges 

18 

X 

19 

Weapon  Name 

20 

— Hull  Defilade 

21 

—  P(Det)  P(fire)/hit  P(f  ire)/niiss 

P(intercept) 

22 

X .XX  x.xx  x.xx 

x.xx 

23 

—  Remge  Degradation  Factors:  0 

30  60  90  120  ISO 

180 

24 

range 1  x.xx  x.xx  x.xx 

X.XX  x.xx  x.xx  x.xx 

32 

rangeN  x.xx  x.xx  x.xx 

x.xx  x.xx  x.xx  x.xx 

33 

— Fully  Exposed 

34 

—  P(Det)  P(fire)/hit  P(fire)/miss 

P(intercept) 

35 

X.XX  x.xx  x.xx 

x.xx 

36 

—  Range  Degradation  Factors:  0 

30  60  90  120  150 

180 

37 

ramgel  x.xx  x.xx  x.xx 

X.XX  x.xx  x.xx  x.xx 

45 

rangeN  x.xx  x.xx  x.xx 

x.xx  x.xx  x.xx  x.xx 

46 

END 

47 

—Smoke  Grenades:  Kgren  P(Launch)  alpha-CLs  Time  to  Deploy  Duration 

48 

XX  x.x  x.xx.xx. 

X  XX . X  XX . 

X 

49 

—Laser  Warning  Recvr:  On/011  P(det)  Pop-smoke  Engage  Hide  nFOV 

Tsearch 

50 

T/F  x.x  T/F 

T/F  T/F  x.x 

x.x 
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Table  14:  Vehicle  File  Input  Definitions 


Line 

Variable 

Definition 

1 

Vehicle  Name 

Seven  character  vehicle  name  must  agree  with  use  in  other  files. 

3 

Turret  Dimensions: 

Height 

Height  in  meters  of  box  which  represents  turret 

1/2  Width 

1/2  width  in  meters  of  box  which  represents  turret 

Front  Length 

Length  in  meters  of  front  part  of  box  which  represents  turret 

Back  Length 

Length  in  meters  of  back  part  of  box  which  represents  turret 

5 

Hull  Dimensions: 

Height’ 

Height  in  meters  of  box  which  represents  hull 

1/2  Width 

1  /2  width  in  meters  of  box  which  represents  hull 

Front  Length 

Length  in  meters  of  front  part  of  box  which  represents  hull 

Back  Length 

Length  in  meters  of  back  part  of  box  which  represents  hull 

Target  Acquisition: 

7 

Optical  Contrast  (HD) 

Optical  contrast  for  this  vehicle  when  in  a  hull  defilade  position.  Used 
when  a  visual  sensor  is  looking  at  it.  It  is  defined  as  the  the  difference 
between  the  average  luminance  of  the  vehicle  and  the  average  luminance  of 
the  background  divided  by  the  average  luminance  of  the  background. 

Optica]  Contrast  (FE) 

Optical  contrast  for  this  vehicle  when  in  a  fully  exposed  position. 
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Table  15;  Vehicle  File  Input  Definitions  -  Continued  (1) 


Line 

Variable 

Definition 

8 

Thermal  Contrast  (HD) 

Thermal  contrast  for  this  vehicle  when  in  a  hull  defilade  position.  Used 
when  a  thermal  sensor  is  looking  at  it.  It  is  defined  as  the  the  difference 
between  the  average  temperature  of  the  vehicle  and  the  average  temperature 
of  the  background  in  degrees  Celsius. 

Thermal  Contrast  (FE) 

Thermal  contrast  for  this  vehicle  when  in  a  fully  exposed  position. 

9 

Charac  Dim 

Characteristic  Dimension,  Used  for  both  visual  and  thermal  sensors.  It  is 
the  square  root  of  the  product  of  the  vehicle’s  height  times  the  vehicles 
width  (in  meters).  Entered  for  hull  defilade,  and  for  fully  exposed.  These 
do  not  neccessarily  need  to  be  the  same  as  the  vehicle’s  box  dimensions  as 
input  on  lines  3  and  5. 

10 

Radar  Cross  Section 

Used  when  the  opposing  sensor  is  a  radar  acquisition  device.  This  is  most 
commonly  referred  to  simply  as  the  cross  section  or  target  size  in  meters 
squared.  More  precisely,  it  is  the  area  intercepting  that  amount  of  power 
which,  when  scattered  equally  in  all  directions,  produces  an  echo  at  the 
radar  equal  to  that  from  the  target. 

12 

Max  speed 

Maximum  speed  in  meters/second  that  the  vehicle  may  move.  For  attacking 
vehicles,  this  is  the  speed  at  which  the  units  move  closer  to  the  defender 
locations.  Even  if  the  vehicle  is  to  be  stationary  in  the  battle,  the  user  must 
input  a  non-zero  maximum  possible  speed.  Note:  This  is  really  a  Radial 
Approach  velocity. 

Acceleration 

Acceleration  of  the  vehicle  in  m/s2 

Deceleration 

Deceleration  of  the  vehicle  in  m/s2 

Pause  in  Defilade 

This  variable  controls  the  movement  of  attackers  when  engaging  a  target , 
and  line-of-sight  (LOS)  is  about  to  break.  An  input  value  of  “1”  causes  the 
attacker  to  move  to  a  hull  defilade  posture  and  halt,  keeping  LOS  to  the 
target  in  order  to  continue  the  engagement.  An  input  value  of  “0”  allows  the 
attacker  to  continue  advancing,  thus  discontinuing  the  engagement  when 
LOS  breaks. 
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Table  16:  Vehicle  File  Input  Definitions  -  Continued  (2) 


Line 

Variable 

Definition 

14 

Time  to  Leave  Battle: 

During  the  battle  certain  situations  prompt  a  vehicle  to  attempt  to  leave 
the  battlefield.  The  inputs  on  this  line  are  the  mean  time  in  seconds  to  leave 
the  battlefield  and  reach  a  full  defilade  posture.  The  model  draws  from  a 
normal  distribution  about  this  mean  when  calculating  the  appropriate  time. 

Jockey 

Time  (secs)  to  leave  battle  for  a  defender  or  an  overwatch  vehicle,  when  it 
pops  down  to  either  move  to  a  new  position  or  to  reload  a  missile  pod. 

When  Empty 

Time  (secs)  to  leave  battle  when  a  unit  (vehicle)  is  out  of  ammunition  and 
tries  to  move  to  a  full  defilade  position  to  avoid  being  killed. 

When  F-killed 

Time  (secs)  to  leave  battle  after  a  unit  (vehicle)  is  F-killed  and  can  no 
longer  fire. 

APS: 

An  active  proieciion  system  (APS)  is  a  vehicle  survivability  enhancement, 
which  may  detect  and  change  the  effectiveness  of  an  incoming  projectile. 

The  APS  protects  an  area  defined  by  an  arc  centered  at  the  front  of  the 
vehicle  and  may  be  deployed  a  set  number  of  times.  The  system  works  in 
four  stages:  detection,  fire,  intercept,  and  degrade. 

16 

Arc  of  Protection 

The  arc  (degrees)  in  front  of  the  vehicle  the  APS  will  cover. 

Num  Launches 

The  number  of  times  the  vehicle  can  activate  its  APS. 

If,  anc 
addiiti 

only  if,  the  number  of  times  the  system  may  activate  is  greater  than  zero  the  user  needs  to  enter  the 
jnal  information  which  defines  the  APS: 

18 

Num  Ranges 

Number  of  range  entries  for  degradation  factors  (see  below).  The  range 
entries  must  be  in  increments  as  specified  in  the  game  file.  The  first  value 
must  be  equal  to  the  range  increment,  and  the  last  range  value  must  be 
greater  than  or  equal  to  the  max  firing  range  of  the  enemy  weapon  system. 
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Table  17:  Vehicle  File  Input  Definitions  -  Continued  (3) 


Line 

Variable 

Definition 

19 

Weapon 

Seven-character  weapon  name,  against  which  the  APS  will  activate. 

22 

Pdet(HD) 

Probability  of  detecting  the  incoming  round  (when  in  hull  defilade) 

Pfh(HD) 

Probability  of  firing  at  an  incoming  round  that  will  hit  (when  in  hull  de¬ 
filade) 

Pfm(HD) 

Probability  of  firing  at  an  incoming  round  that  will  miss  (when  in  hull 
defilade) 

Pint(HD) 

Probability  of  intercepting  the  incoming  round  (when  in  hull  defilade) 

24-32 

Range 

Range  increment  (m)  for  which  the  degradation  factors  apply 

Degradation  Factors 

The  degradation  factors  for  each  30  degree  sector  within  the  arc  of  protec¬ 
tion.  These  factors  are  multiplied  times  the  lethality  of  the  incoming  round 
(i.e.,  if  P(kill)=,6  and  deg.  factor=.2,  the  resultant  P(kill)=.12). 

35 

Pdet(FE) 

Probability  of  detecting  the  incoming  round  (when  fully  exposed) 

Pfh(FE) 

Probability  of  firing  at  an  incoming  round  that  will  hit  (when  fully  exposed) 

Pfm(FE) 

Probability  of  firing  at  an  incoming  round  that  will  miss  (when  fully  ex¬ 
posed) 

Pint(FE) 

Probability  of  intercepting  the  incoming  round  (when  fully  exposed) 
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Table  18;  Vehicle  File  Input  Definitions  -  Continued  (4) 


Line 

Variable 

Definition 

37-45 

Range 

Range  increment  (m)  for  which  the  degradation  factors  apply 

Degradation  Factors 

The  degradation  factors  for  each  30  degree  sector  within  the  arc  of  protec- 
tion.  These  factors  are  multiplied  times  the  lethality  of  the  incoming  round 
(i.e.,  if  P(kill)=.6  and  deg.  factor=.2,  the  resultant  P(kill)=.12). 

Additional  sets  of  input  consisting  of  (weapon  name,  probabilities,  and  degradation)  are  entered  next  for  each 
weapon  against  which  this  system  is  effective.  When  all  affected  weapons  have  been  entered,  enter  “END"'  as 
the  next  line. 

46 

END 

End  of  APS  section. 

Smoke  Grenades: 

Another  survivability  enhancement  modeled  is  an  on  board  smoke  grenade 
system.  The  system  has  the  ability  to  detect  an  incoming  round  and  to 
deploy  a  smoke  cloud  around  the  target  vehicle  which  affects  target  acqui¬ 
sition  by  and  of  this  vehicle. 

48 

Num  Grenades 

Number  of  times  the  grenade  launcher  can  fire.  (This  is  not  neccessarily 
the  total  number  of  grenades.) 

P(Launch) 

Probability  that  the  system  will  detect  and  deploy. 

Alpha-CL(opt) 

Level  of  smoke  which  affects  optical  sensors. 

Alpha-CL(ther) 

Level  of  smoke  which  affects  thermal  sensors. 

Alpha-CL(radar) 

Level  of  smoke  which  affects  radar  sensors. 

Time  to  Deploy 

The  time  (sec)  from  launch  of  the  grenade  to  the  effective  formation  of  the 
smoke  cloud  around  the  vehicle. 

Duration 

The  effective  duration  (sec)  of  the  smoke  cloud  from  the  time  it  forms. 
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Table  19:  Vehicle  File  Input  Definitions  -  Continued  (5) 


[WPBi 

Variable 

Definition 

LWR: 

The  last  survivability  enhancement  is  a  laser  warning  receiver  (LWR)  sys¬ 
tem  which  may  be  activated  when  the  vehicle  gets  lased  prior  to  being 
engaged.  For  the  LWR  to  react,  the  engaging  weapon  system  must  be  us¬ 
ing  a  laser  range  finder  (defined  in  the  weapon  input  file).  Three  reactions 
by  the  lased  vehicle  are  possible:  1)  Pop  smoke  grenades,  2)  Turn  and 
engage  the  combatant  who  lased,  and  3)  Attempt  to  reach  a  full  defilade 
posture.  Any  combination  of  these  reactions  can  be  played  simultaneously. 

50 

If  LWR 

If  there  is  an  LWR  on  board,  true  or  false  (T/F). 

P(det) 

Probability  that  the  LWR  wdll  detect  that  it  has  been  lased,  and  react. 

Pop-Smoke 

T/F.  If  T,  user  must  enter  appropriate  values  on  the  smoke  grenade  line  (48 
above).  If  smoke  grenades  are  to  be  triggered  by  LWR  only,  the  probability 
of  sensing,  PfLaunch),  on  line  48  above  must  be  set  to  0.0. 

Engage 

T/F.  T  if  tactic  is  to  turn  to  engage  combatant  who  lased.  (If  T,  see  last 
two  input  variables  on  this  line.) 

Hide 

T/F.  T  if  tactic  is  to  attempt  to  reach  a  full  defilade  position. 

Num  FOV 

When  the  Engage  tactic  is  played,  the  LWR  can  achieve  different  levels  of 
accuracy  when  pointing  in  the  direction  of  the  threat.  If  the  LWR  can  give 
a  precise  location  of  the  enemy,  the  entry  for  this  input  is  1.0.  The  lased 
vehicle’s  observer  then  searches  in  NFOV  and  the  only  requirement  is  to 
check  if  .75  line  pairs  can  be  resolved  across  the  target  (detection  criteria). 
Otherwise  the  user  should  enter  the  general  area  to  search  for  the  threat 
as  a  number  of  fields  of  view  of  the  appropriate  sensor.  In  this  case,  the 
lased  vehicle’s  observer  searches  in  WFOV  for  these  number  of  fields  of 
view  for  the  enemy  using  detection  criteria  (.75  line  pairs).  Once  acquired 
in  WFOV,  the  observer  must  then  attempt  to  acquire  the  enemy  in  NFOV, 
as  usual. 

Tsearch 

When  the  Engage  tactic  is  played,  the  time  (sec)  to  search  for  the  enemy 
before  resuming  normal  search. 
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2.4  Weapon  File 


There  is  a  BLUE  weapons  file,  bweap^  and  a  RED  weapons  file,  rweap.  Each  file  contains  subsections 
which  describe  one  weapon  system  each.  For  each  weapon  subsection  the  user  defines  firing  times, 
reliability,  times  to  reload,  type  of  round  etc.  The  general  structure  of  the  Weapon  File  is  shown  in 
Table  20.  Tables  21  through  28  list  the  Weapon  File  input  variable  definitions. 


Table  20:  Weapon  File 


Line 

0 

*♦  Conunent  Line(s) 

1 

Weapon  Najne 

2 

—Type  FireMax  Krounds  Halt-to-fire 

Tactic  Hrpt  LRF  isLO 

3 

XX  XXXX .  XX 

X 

X  XX  T/F  T/F 

4 

— Inputs  by  Range:  PCsense),  T(flight),  TCfirst),  T(fixed),  Reliab 

5 

x.xx  x.xx  x.xx  x.xx 

M 

H 

H 

H 

H 

H 

*♦  P (sense) 

6 

XX. X  XX. X  XX. X  XX. X 

.XX.X  xx.x 

•*  T(flight) 

7 

XX. X  XX. X  XX. X  XX. X 

.xx.x  xx.x 

**  T(f irst) 

8 

XX.  X  XX.  X  XX.  X  XX.  X 

.xx.x  xx.x 

♦  •  T(fixed) 

9 

x.xx  x.xx  x.xx  x.xx 

.x.xx  x.xx 

♦♦  Reliability 

10 

— Jockeying:  If-Pop  N(jockey)  T(jockey) 

11 

X  XX 

xx.x 

12 

— Subsequent  Firing:  TCmedian) 

T(min) 

13 

X  .X 

x.x 

14 

— Burst  Fire:  Rate-of-Fire  Nrnds/burst 

15 

x.x 

X 

16 

— Missiles:  Disengage  NinPod  Ntgts  T(reload)  P(abt)/smk  P(abt)/terr 

17 

X  X 

X  XX.X 

x.xx  x.xx 

18 

— Multiple  Engagement:  If-Mult 

T(mult)  N(mult)  Reload-part 

19 

X 

H 

H 

H 

X  X 

20 

— Lock-on  Data:  Max  lock 

-on  tries 

21 

X 

22 

— Battery  Coolant  Unit  cooldown  time 

23 

XX.  X 

24 

— Prob (Lock-on)  by  Range 

:  stat/HD,  stat/FE,  moving/FE  j 

25 

x.x  x.x  x.x 

.  x.x  x.x 

*♦  Stat/HD 

26 

x.x  x.x  x.x 

.  x.x  x.x 

♦*  stat/FE 

27 

x.x  x.x  x.x 

.  x.x  x.x 

moving/FE 

28 

— Mean (Lock-on)  by  Range 

:  Btat/HD,  stat/FE,  moving/FE 

29 

XX . X  XX . X  XX . x 

.xx.x  xx.x 

*♦  stat/HD 

30 

XX.X  XX.X  xx.x 

.xx.x  xx.x 

•*  stat/FE 

31 

XX . X  XX . X  XX . X 

.xx.x  xx.x 

**  moving/FE 

32 

— Max (Lock-on)  by  Remge: 

8tat/HD,  stat/FE,  moving/FE 

33 

xx.x  xx.x  xx.x  . . 

.xx.x  xx.x 

*♦  stat/HD 

34 

xx.x  xx.x  xx.x  . . 

.xx.x  xx.x 

♦*  stat/FE 

35 

xx.x  xx.x  xx.x  .  . 

.xx.x  xx.x 

♦♦  moving/FE 

36 

— Range-In 

37 

T/F 

ZZZ 
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Table  21:  Weapon  File  Input  Definitions 


Line 

Variable 

Definition 

1 

Weapon  Name 

Seven  character  weapon  name  must  agree  with  one  of  the  weapon  system 
names  in  the  unit  deployment  file. 

3 

Type 

Integer  value  from  1  to  4  defining  the  type  of  round: 

1  =  Kinetic  Energy  Round  (KE) 

2  =  High  Explosive  Anti-Tank  (HEAT) 

3  =  Fire  and  Forget  Missile  (FAF) 

4  =  Command  Line-of-Sight  Missile  (CLOS) 

FireMax 

;  Maximum  effective  firing  range  of  the  weapon 

Nrounds 

Total  number  of  rounds  on  board 

Halt-to-fire 

Integer  value  defining  whether  system  must  halt  to  fire. 

0  =  System  may  fire  weapon  on  the  move 

1  =  System  must  halt  to  fire  w^eapon 

Tactic 

Integer  value  from  1  to  3  defining  the  disengagement  tactic. 

1  =  Disengage  after  Catastrophic  Kill 

2  =  Disengage  after  hitting  the  target 

3  =  Disengage  after  firing  Nrpt  rounds  at  the  target 

(see  next  input) 

Nrpt 

Number  of  rounds  to  fire  at  a  target  before  disengaging  (only  used  when 
playing  tactic  3  above) 

LRF 

T  (true)  if  this  weapon  system  uses  a  laser  range  finder  prior  to  firing  its 
first  round  of  an  engagement.  The  play  of  the  range  finder  does  not  change 
the  way  accuracy  is  played.  The  only  effect  of  setting  this  input  to  True  is 
that  it  will  now  activate  laser  warning  receivers  on  target  vehicles.  Input 
F  for  false  if  the  weapon  uses  no  LRF. 

isLO 

T  (true)  if  this  weapon  is  a  lock-on  before  launch  system,  otherwise,  set  to 
F  (false). 
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Table  22:  Weapon  File  Input  Definitions  -  Continued  (1) 


Definition 

The  next  five  lines  contain  data  which  are  input  by  range.  These  data  are  input  in  range  increments  as 
specified  in  the  game  control  file.  Note:  The  first  value  on  each  line  should  be  for  the  range  equal  to  this 
increment  (e.g.,  500  meters),  and  not  for  range  equal  to  0  meters.  There  must  be  enough  values  on  each  line 
to  cover  up  to  and  including  the  maximum  firing  range  set  on  line  three. 

5 

P(sense) 

Probability  that  the  firer  will  sense  the  impact  location  of  a  round  that 
misses  its  target. 

6 

T(flight) 

The  time  (secs)  of  flight  of  the  round  to  the  various  ranges. 

7 

T(first) 

Median  time  (secs)  to  fire  the  first  round  of  an  engagement.  Log-normal 
distribution  draw. 

8 

T(fixed) 

Fixed  time  (secs)  between  rounds  when  using  an  auto-loader.  Always  added 
when  calculating  time  to  fire. 

9 

Reliability 

Probability  that  the  round  is  reliable  (i.e.,  not  a  dud). 

11 

Jockeying: 

Groundwars  allows  systems  which  are  either  in  defense  or  overwatch  to 
increase  survivability  by  moving,  for  a  specified  duration,  to  a  full  defilade 
posture  at  certain  points  in  the  battle.  The  input  variables  on  this  line 
concern  jockeying. 

If-Pop 

Defines  whether  a  missile  system  pops  down  (into  full  defilade)  to  reload. 

The  missile  system  remains  full  defilade  for  the  specified  reload  time, 

T(reload),  mentioned  later.  Set  to  1  if  it  should  pop-down,  0  if  not. 

N(jockey) 

Number  of  shots  fired  before  a  KE  weapon  system  will  jockey.  A  value  of 

0  specifies  that  the  system  will  not  jockey. 

T(jockey) 

The  duration  of  time  (sec)  a  KE  system  remains  in  full  defilade  during  the 
jockey  maneuver. 
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Table  23:  Weapon  File  Input  Definitions  -  Continued  (2) 


Line 

Variable 

Definition 

13 

Subsequeni  Firing  Times: 

This  line  characterizes  the  subsequent  firing  times  for  the  system.  They  are 
applied  to  all  rounds  fired  at  a  target  after  the  first  for  a  specific  engagement 
of  firer/target.  Before  a  subsequent  round  is  fired,  a  random  draw  is  made 
from  a  log-normal  distribution  about  the  median  time  to  determine  the 
random  re-aiming  time.  This  time  is  added  to  the  fixed  time  between 
rounds  if  an  auto-loader  is  being  used.  If  this  total  time  is  less  than  the 
minimum  time,  then  the  minimum  time  to  fire  a  subsequent  round,  T(min), 
will  be  used  as  the  subsequent  firing  time. 

T(median) 

Median  time  (sec)  to  fire  a  subsequent  round. 

T(min) 

Minimum  time  (sec)  to  fire  a  subsequent  round. 

15 

Rate  of  Fire 

Rounds  per  second  within  burst.  Use  1.0  if  not  playing  burst  fire. 

Nrnds/burst 

Number  of  rounds  in  a  single  burst.  Use  1  if  not  playing  burst  fire. 

Table  24:  Weapon  File  Input  Definitions  -  Continued  (3) 


Like 

Variable 

Definition 

17 

Missile  System  Aiirihuies: 

Disengage 

For  missile  systems  which  remain  exposed  during  reload  (if-pop  equal  0), 
there  are  two  choices  for  continuing  an  engagement.  The  system  may  be 
able  to  keep  its  fix  on  its  target  and  therefore  resume  the  engagement  of 
that  target  upon  finishing  reloading.  Some  systems  such  as  a  hand-held 
one-soldier  system  cannot  maintain  a  fix  on  the  target  and  must  begin  the 
acquisition  process  anew  after  reloading.  If  the  system  cannot  maintain  a 
fix  on  the  target  while  reloading  and  must  disengage,  then  Disengage  should 
be  set  to  1.  If  the  system  can  maintain  a  fix  while  reloading,  Disengage 
should  be  set  to  0. 

NinPod 

Number  of  missiles  on  board  which  are  ready  to  fire.  It  is  this  number 
which  will  be  reloaded  when  the  ready  rounds  are  depleted. 

Ntgts 

The  number  of  rounds  which  can  be  fired  nearly  simultaneously  when  play¬ 
ing  Multiple  Engagement.  Ntgts  should  be  set  to  1  when  not  playing  mul¬ 
tiple  engagement. 

T(reload) 

The  time  (sec)  required  to  reload  the  ready-to-fire  missile  pod. 

P(abt)/smk 

Probability  that  the  missile  will  abort  due  to  an  increase  in  the  atmospheric 
attenuation  (smoke). 

P(abt)/terr 

Probability  that  the  missile  will  abort  when  a  break  in  line-of-sight  occurs 
between  firer  and  target  during  missile  flight. 
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Table  25:  Weapon  File  Input  Definitions  -  Continued  (4) 


Line 

Variable 

Definition 

19 

Muiiple  Engagemtni  Missiles: 

This  line  allows  the  play  of  a  missile  system  which  can  queue  targets  and 
fire  at  them  nearly  simultaneously.  A  system  may  only  multiply  engage  if 
its  weapon  type  is  a  fire  and  forget  missile. 

If- Mult 

If  multiple  engagement  is  desired.  1  for  yes,  0  for  no. 

T(mult) 

The  time  from  initial  detection  to  search  for  additional  targets  before  be¬ 
ginning  the  engagement.  After  t(mult)  has  elapsed  the  firer  will  begin  the 
engaging  whatever  number  of  targets  have  been  acquired. 

N(mult) 

The  total  number  of  targets  to  try  to  multiply  engage.  After  n(mult)  tar¬ 
gets  have  been  detected,  the  firer  will  fire  a  single  shot  at  each  target  and 
disengage. 

Reload*part 

When  playing  multiple  engagement,  a  system  is  able  to  reload  part  of  its 
missile  pod  so  that  it  always  has  a  full  pod  when  engaging  targets.  Reload- 
part  should  be  set  to  1  if  the  system  can  reload  part  of  the  pod,  and  if  that 
is  the  desired  tactic. 
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Table  26:  Weapon  File  Input  Definitions  •  Continued  (5) 


Variable 

Definition 

Lock-on  Before  Launch  Systems: 

Lines  21  through  35  describe  input  for  a  lock-on  before  launch  system,  (e.g., 
Javelin).  This  section  should  only  be  present  if  the  lock-on  parameter,  isLO, 
on  line  3  above  is  set  to  True.  The  methodology  is  as  follows:  After  a  tar¬ 
get  is  acquired,  a  uniform  random  number  [0,1]  is  drawn.  If  the  random 
number  is  less  than  or  equal  to  the  probability  of  lock-on,  a  lock-on  event  is 
scheduled  in  i  seconds.  The  time  i  is  sampled  from  a  log-normal  distribu¬ 
tion  using  the  mean  lock-on  time,  and  is  bounded  by  the  maximum  value 
imax(lock-on),  and  added  with  the  BCU  cooldown  time.  If  the  random 
number  drawn  was  greater  than  the  probability  of  lock-on,  a  failed-lock-on 
aiiempi  completion  is  scheduled  in  t  seconds  (where  t  in  this  case  is  BCU 
cooldown  time  plus  tmax(lock-on)).  At  lock-on  attempt  completion  time, 
the  following  will  occur.  If  the  event  was  a  lock-on  success  then  a  firing 
time  is  scheduled  (based  on  time  to  fire  first  round  and  t-fixed).  If  the 
event  was  a  lock-on  failure  then  the  number  of  lock-on  tries  is  examined. 

If  the  number  of  lock-on  tries  to  this  point  is  less  than  max-lock-on-tries, 
then  another  lock-on  attempt  is  scheduled  immediately.  If  the  number  of 
lock-on  tries  to  this  point  is  equal  to  max-lock-on-tries,  then  the  firer  dis¬ 
engages  the  target  and  will  enter  search  mode  to  look  for  new  targets.  If 
no  new  targets  are  found,  the  firer  will  return  to  this  target  to  try  another 
series  of  lock-on  attempts  in  n  seconds.  This  time  n  is  input  as  TLOOK 
and  is  the  same  time  used  to  reschedule  a  narrow-field-of  view  acquisition 
attempt  after  a  wude-field-of-view  success  but  narrow-field-of- view  failure. 

21 

Max  lock-on  tries 

Maximum  number  of  times  the  gunner  will  try  to  achieve  lock-on  to  target 
before  giving  up  and  looking  for  other  targets. 

23 

BCU  Ctime 

Battery  Coolant  Unit  cooldown  time  in  seconds.  This  is  the  time  it  takes 
for  a  disposable  assembly  such  as  a  BCU  (battery  coolant  unit)  on  a  Javelin 
to  mate  to  the  round  to  provide  both  power  and  cooling  gases  to  the  seeker. 
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Table  27:  Weapon  File  Input  Definitions  -  Continued  (6) 


Line 

Variable  Definition 

The  next  three  lines  contain  data  which  are  input  by  range.  These  data  are  input  in  range  increments  as 
specified  in  the  game  control  file.  Note:  The  first  value  on  each  line  should  be  for  the  range  equal  to  this 
increment  (e.g.,  500  meters),  and  not  for  range  equal  to  0  meters.  There  must  be  enough  values  on  each  line 
to  cover  up  to  and  including  the  maximum  firing  range  set  on  line  three. 

25 

P(Lock-on)  stat/HD 

Probability  that  the  missile  will  lock-on  to  a  target  which  is  stationary  and 
hull  defilade. 

26 

P(Lock-on)  stat/FE 

Probability  that  the  missile  will  lock-on  to  a  target  which  is  stationary  and 
fully  exposed. 

27 

P(Lock>on)  mov/FE 

Probability  that  the  missile  will  lock-on  to  a  target  which  is  moving  and 
fully  exposed. 

The  next  three  lines  also  contain  data  which  are  input  by  range,  to  be  input  similarly  to  the  three  lines  above. 

29 

Mean(Lock-on)  stat/HD 

Mean  time  (sec)  for  the  missile  to  lock  onto  a  target  which  is  stationary 
and  hull  defilade. 

30 

Mean(Lock-on)  stat/FE 

Mean  time  (sec)  for  the  missile  to  lock  onto  a  target  which  is  stationary 
and  fully  exposed. 
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Table  28:  Weapon  File  Input  Definitions  -  Continued  (7) 


Line 

Variable 

Definition 

31 

Mean(Lock-on)  mov/FE 

Mean  time  (sec)  for  the  missile  to  lock  onto  a  target  which  is  moving  and 
fully  exposed. 

The  nexi  three  lines  also  contain  data  which  are  input  by  range. 

33 

Max(Lock-on)  stat/HD 

Maximum  time  (sec)  for  the  missile  to  lock  onto  a  target  which  is  stationary 
and  hull  defilade. 

34 

Max(Lock-on)  stat/FE 

Maximum  time  (sec)  for  the  missile  to  lock  onto  a  target  which  is  stationary 
and  fully  exposed. 

35 

Max(Lock-on)  mov/FE 

Maximum  time  (sec)  for  the  missile  to  lock  onto  a  target  which  is  moving 
and  fully  exposed. 

The  next  data  line  (37)  should  only  be  present  if  the  system  is  a  bursi-fire  weapon  (i.e.,  the  input  variable 
Nrnds/burst  on  line  15  above  was  set  to  a  value  greater  than  one). 

37 

Range-In 

T  or  F  for  true  or  false.  Ranging-in  is  a  process  used  by  gunners  to  adjust 
fire  on  the  target.  The  range-in  process  lowers  accuracy  errors  for  weapon 
systems  with  limited  fire  control,  since  the  gunner  must  correct  for  errors 
associated  with  target  range  estimation,  system  biases,  etc.  The  gunner 
achieves  more  accurate  fire  by  adjusting  the  aimpoint  in  response  to  the 
perceived  impact  location  of  the  preceding  round.  If  this  variable  is  set  to 
T,  then  a  Ranging-in  file  must  be  input  (described  later). 
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2.5  Sensor  File 


Groundwars  allows  the  user  to  play  optical,  thermal,  or  millimeter  wave  devices,  with  a  total  of  6 
sensors  for  both  sides.  As  with  the  vehicle  and  weapon  files,  the  sensor  file  is  a  group  of  subsections, 
one  for  each  sensor.  The  BLUE  sensor  file  is  named  bsens  and  the  RED  is  rsens. 

For  optical  and  thermal  devices,  the  model  uses  a  form  of  the  NVESD  (Night  Vision  Electronic 
Sensors  Directorate)  target  acquisition  methodology  to  determine  acquisition  capability.  Ground- 
wars  now  models  both  wide  and  narrow  field  of  view  search,  and  input  data  is  needed  for  both.  For 
observers  having  both  wide  and  narrow  field  of  view  on  their  sensor,  Groundwars  starts  their  search 
process  with  observers  initially  using  their  wide  field  of  view  (WFOV).  After  successful  acquisition 
in  WFOV,  the  observer  will  switch  to  narrow  field  of  view  (NFOV)  and  attempt  to  find  the  target 
based  on  the  desired  level  of  target  discrimination  for  engaging  in  NFOV.  If  the  target  is  not  acquired 
in  NFOV,  the  observer  will  switch  back  to  WFOV  to  continue  searching. 

The  level  of  target  discrimination  desired  is  specified  by  the  user  in  the  sensor  input  file  for 
both  WFOV  and  NFOV.  The  Johnson  Line  Pair  Criteria,  N50,  are  an  empirically  determined  set 
of  values  used  to  define  four  levels  of  target  discrimination.  These  values,  N50,  are  the  number  of 
resolved  cycles  such  that  half  the  observers  can  discriminate  a  target  at  the  respective  level.  The 
discrimination  levels  are  defined  as  follows: 

•  Detection  is  the  ability  of  an  observer  to  distinguish  that  an  object  is  of  military  interest. 

•  Classification  is  the  ability  to  distinguish  a  target  by  general  type;  i.e.  a  tracked  versus  a 
wheeled  vehicle. 

•  Recognition  is  the  ability  to  distinguish  between  two  targets  of  similar  type;  i.e.  between  two 
types  of  tracked  vehicles,  such  as  APCs  and  tanks. 

•  Identification  is  the  ability  to  discriminate  the  exact  model  of  a  target;  i.e.  a  T72  or  Ml  tank. 

In  order  to  reflect  the  combination  of  vertical  and  horizontal  resolution  in  the  two  dimensional 
MRTD  (Minimum  Resolvable  Temperature  Difference),  it  is  necessary  to  adjust  the  traditional 
Johnson  cycle  criteria.  The  following  recommendations  have  been  made  by  NVESD  for  N50  values 
when  using  2D  MRTD  methodology: 

•  Detection  -  0.75 

•  Classification  -  1.50 

•  Recognition  -  3.00 

•  Identification  -  6.00 


These  cycle  criteria  should  be  used  across  all  sensors:  DVO,  TV,  12,  and  thermal  imagers 
(both  first  and  second  generation), 

o  The  performance  of  a  millimeter  wave  sensor  in  the  model  is  fixed  except  for  changes  in  the 

atmosphere  and  differences  in  target  RCS.  The  required  data  for  optical  and  thermal  devices  is 
different  from  that  for  a  radar  device,  so  the  structures  of  the  subsection  for  the  two  types  will  be 
listed  in  separate  tables.  Table  29  lists  the  input  structure  for  a  VISUAL  or  THERMAL  sensor. 
Table  34  lists  the  input  structure  for  a  RADAR  sensor.  Tables  30  through  33  lists  the  input  variable 
definitions  for  the  VISUAL  or  THERMAL  sensor  file  and  Table  35  lists  the  definitions  for  the 
RADAR  file. 
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Table  29:  Sensor  File  -  VISUAL/THERMAL 


Line 

0 

♦♦  Comment  Line(s) 

1 

Sensor  Name 

2 

—  Sensor  Type:  VISUAL  or  THERMAL 

3 

—  Data  Type:  TWENTY  or  NVLEXP 

(If  data  type  is  TWENTY,  enter  two  20-point  curves  for  each  FOV: 
one  curve  for  Minimum  Resolvable  Contrast  (MRC)  or  Tempera¬ 
ture  Difference  (MRTD),  and  another  curve  for  Spatial  Frequency) 

4 

~  NFOV 

5 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

6 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

7 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

8 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

9 

—  VFOV 

10 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

11 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

12 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

13 

x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

(If  data  type  is  NVLEXP,  enter  7  coefficients  for  each  FOV) 

4 

—  NFOV 

5 

XX. XX  XX. XX  XX. XX  XX. XX  XX. XX  XX. XX  XX. XX 

6 

—  WFOV 

7 

XX. XX  XX. XX  XX. XX  XX. XX  XX. XX  XX. XX  XX. XX 

(lines  8  through  13  omitted  for  data  type  NVLEXP) 

14 

—  Horizontal  FOS,  Vertical  FOS 

15 

XX. X  XX. X 

16 

—  Horizontal  NFOV,  Vertical  NFOV 

17 

XX. X  XX. X 

18 

—  Horizontal  WFOV,  Vertical  WFOV 

19 

XX . X  XX . X 

20 

—  NFOV  Magnification,  WFOV  Magnification 

21 

x.x  x.x 

22 

—  NFOV  Stat  Acq  Level,  NFOV  Mov  Acq  Level,  tnfov 

23 

x.x  x.x  XX.  X 

24 

—  WFOV  Stat  Acq  Level,  WFOV  Mov  Acq  Level 

25 

x.x  x.x 

26 

—  N(dets),  pfalse(HD),  pfalse(FE) 

27 

X  x.xx  x.xx 

28 

—  Pinpoint  probabilities 

29 

veaponl  x.xx 

30 

veapon2  x.xx 

n 

weaponN  x.xx 

n+1 

END 
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Table  30.  VISUAL/THERMAL  Sensor  File  Input  Definitions 


Line 

Variable 

Definition 

1 

Sensor  Name 

Character  String  must  agree  with  one  of  the  sensor  names  in  the  unit  de- 
ployment  file. 

2 

Sensor  Type 

Character  String:  VISUAL  or  THERMAL 

3 

Data  Type 

Character  String:  TWENTY  or  NVLEXP.  Data  for  visual  or  thermal  sen¬ 
sors  can  be  input  in  one  of  two  ways.  For  TWENTY,  the  user  enters  two 
performance  curves  for  NFOV  and  two  for  WFOV,  which  contain  twenty 
points  each  (MRTD  or  MRC,  and  then  spatial  frequency).  For  NVLEXP 
the  user  enters  seven  coefficients  to  fit  a  sixth  degree  polynomial. 

The  following  lines  (4  through  13)  are  input  when  Data  Type  (above  in  line  3)  is  TWENTY. 

4 

NFOV 

Narrow  Field  of  View  (Header) 

5 

MRC  or  MRTD 

MRC  (if  VISUAL  sensor)  or  MRTD  (if  THERMAL  sensor)  curve  values  1 
through  10  for  NFOV 

6 

MRC  or  MRTD 

MRC  (if  VISUAL  sensor)  or  MRTD  (if  THERMAL  sensor)  curve  values  11 
through  20  for  NFOV 

B 

SpaFreq 

Spatial  Frequency  curve  values  1  through  10  for  NFOV 

8 

SpaFreq 

Spatial  Frequency  curve  values  11  through  20  for  NFOV 

9 

WFOV 

Wide  Field  of  View  (Header) 
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Table  31;  VISUAL/THERMAL  Sensor  File  Input  Definitions  -  Continued  (1) 


BWSSI 

Variable 

Definition 

■ 

MRC  or  MRTD 

MRC  (if  VISUAL  sensor)  or  MRTD  (if  THERMAL  sensor)  curve  values  1 
through  10  for  WFOV 

11 

MRC  or  MRTD 

MRC  (if  VISUAL  sensor)  or  MRTD  (if  THERMAL  sensor)  curve  values  11 
through  20  for  WFOV 

12 

SpaFreq 

Spatial  Frequency  curve  values  1  through  10  for  WFOV 

13 

SpaFreq 

Spatial  Frequency  curve  values  11  through  20  for  WFOV 

The  following  lines  through  7)  are  input  when  Data  Type  (above,  line  3)  is  NVLEXP, 

4 

NFOV 

Narrow  Field  of  View  (Header) 

5 

NVLEXP 

Seven  coefficients  for  calculating  spatial  frequency  for  NFOV 

6 

WFOV 

Wide  Field  of  View  (Header) 

7 

NVLEXP 

Seven  coefficients  for  calculating  spatial  frequency  for  WFOV 

(Lines  8-13  omitted  for  data  Type  NVLEXP) 

Lines  15  through  19  give  the  fields  of  view  (FOV)  and  search  (FOS).  The  FOV  are  characteristic  of  the 
sensor,  and  the  FOS  are  based  on  battlefield  responsibility. 

15 

Hor  FOS 

Horizontal  Field  of  Search  (degrees) 

Ver  FOS 

Vertical  Field  of  Search  (degrees) 
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Table  32:  VISUAL/THERMAL  Sensor  File  Input  Definitions  -  Continued  (2) 


Line 


Variable 


Definition 


17 


19 


21 


Hor  NFOV 


Ver  NFOV 


Hor  WFOV 


Ver  WFOV 


NFOV  Mag 


WFOV  Mag 


Horizontal  Narrow  Field  of  View  (degrees) 


Vertical  Narrow  Field  of  View  (degrees) 


Horizontal  Wide  Field  of  View  (degrees) 


Vertical  Wide  Field  of  View  (degrees) 


Narrow  Field  of  View  Magnification 


Wide  Field  of  View’  Magnification 


23 


NS  Acq 


NFOV  Stationary  Acquisition  Level  (level  of  acquisition  desired  against 
stationary  targets,  in  values  of  N50,  the  Johnson  Line  Pair  Criteria). 


NM  Acq 


NFOV  Moving  Acquisition  Level  (level  of  acquisition  desired  against  mov¬ 
ing  targets,  in  values  of  N50,  the  Johnson  Line  Pair  Criteria). 


T(NFOV) 


Time  (sec)  to  search  in  NFOV  before 
WFOV,  if  a  target  is  not  acquired. 


giving  up  and  switching  back  to 


25 


WS  Acq 


WFOV  Stationary  Acquisition  Level  (level  of  acquisition  desired  against 
stationary  targets,  in  values  of  N50,  the  Johnson  Line  Pair  Criteria). 


WM  Acq 


WFOV  Moving  Acquisition  Level  (level  of  acquisition  desired  against  mov¬ 
ing  targets,  in  values  of  N50,  the  Johnson  Line  Pair  Criteria). 
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Table  33:  VISUAL/THERMAL  Sensor  File  Input  Definitions  -  Continued  (3) 


Line 

Variable 

Definition 

27 

N(dets) 

The  number  of  targets  which  may  be  detected  concurrently  (hunter-killer) 
by  a  system  with  this  sensor.  If  this  sensor  must  remain  fixed  on  the  target 
while  the  gunner  services  the  target,  n(dets)  should  be  set  to  1.  If  other 
targets  can  be  detected  while  the  gunner  is  busy,  n(deis)  should  be  set  to 
greater  than  1. 

pfalse(HD) 

Probability  that  a  detected  target  in  hull  defilade  is  a  false  target.  When 
a  hull  defilade  target  is  first  detected,  a  random  draw  is  made  against  this 
probability  to  see  if  a  false  target  will  be  randomly  substituted  for  the  real 
target. 

pfalse(FE) 

Probability  that  a  detected  target  that  is  fully  exposed  is  a  false  target. 

When  a  fully  exposed  target  is  first  detected,  a  random  draw  is  made  against 
this  probability  to  see  if  a  false  target  will  be  randomly  substituted  for  the 
real  target. 

The  k 
the  ba 
We  ape 
input, 

isi  section  de) 
tile.  On  each 

m  names  mus 

enter 

fines  the  probabiltites  of  this  sensor  detecting  the  firing  signatures  of  other  weapons  in 
line  enter  another  weapon  name  and  the  probability  of  detection  given  the  weapon  fires, 
i  match  weapon  names  as  input  in  the  weapon  file.  When  all  desired  weapon  have  been 
to  end  the  pinpoint  section. 

29-n 

Weapon 

Character  String  of  firing  weapon 

P(pinp) 

Probability  of  sensor  detecting  weapon  by  its  flash. 

n+1 

END 

End  of  Pinpoint  section. 
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Table  34:  Sensor  File  -  RADAR 


Line 

0 

♦  ♦  Conunent  Line(s) 

1 

Sensor  lame 

2 

“  RADAR 

3 

—  If -rain.  Clutter 

4 

X  z.z 

5 

— I(dets),  pfal8e(HD),  pfalseCFE) 

6 

z  z.xx  z.xx 

7 

—  Pinpoint  probabilities 

8 

veaponl  x.zx 

9 

veapon2  x.zx 

n 

weaponN  x.zx 

n+1 

END 

Table  35:  RADAR  Sensor  File  Input  Definitions 


Line 

Variable 

Definition 

1 

Sensor  Name 

Character  String  must  agree  with  one  of  the  sensor  names  in  the  unit  de¬ 
ployment  file. 

2 

Sensor  Type 

Character  String:  RADAR 

Rain  and  clutter  will  affect  radar  acquisition. 

If-rain 

Input  1  for  rain,  else  0  for  no  rain. 

Clutter 

Level  of  Clutter.  Use  1.0  for  Low  Clutter,  and  greater  than  1.0  for  High 
Clutter. 

5  to  END 

Same  as  lines  26  to  END  in  VISUAL/THERMAL  Sensor  File. 
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2.6  Accuracy  File 


For  each  weapon  system  defined  in  the  two  unit  deployment  files,  there  must  be  a  file  which  contains 
weapon  system  delivery  accuracies.  BLUE  accuracy  files  have  the  form  bacc?  where  ?  is  an  integer 
representing  the  number  of  the  blue  weapon  system.  For  example,  if  there  are  three  different  blue 
weapon  systems,  the  blue  accuracy  files  must  be  named,  baccl^  bacc2j  and  baccS.  The  same  structure 
holds  for  all  RED  accuracy  files,  race?.  Each  file  has  the  structure  shown  in  either  Tables  36  and  37 
for  non-burst-fire  systems,  or  Table  38  for  a  burst-fire  weapon. 

The  model  requires  shot  biases  and  dispersions  for  three  situations:  stationary  firer  against  a 
stationary  target,  a  stationary  firer  against  a  moving  target,  and  a  moving  firer  against  a  stationary 
target.  Ground  wars  does  not  model  a  moving  firer  against  a  moving  target,  and  so  does  not  require 
input  data  for  this  situation. 

The  file  is  free  formatted,  and  all  lines  which  begin  with  an  are  comment  lines  included 
for  clarity;  comment  lines  may  be  added  or  removed  between  groups  of  data,  but  not  within  a  group 
of  data.  All  ranges  are  in  meters,  and  all  biases  and  errors  are  in  mils  (angular  measurement  equal 
to  1/6400  of  a  circle). 

There  exist  three  types  of  errors  w^hich  are  read  into  the  model  and  can  be  classified  according 
to  how  long  they  persist.  Fixed  biases  are  those  which  persist  over  many  engagements.  Variable 
biases  are  caused  by  transient  effects  such  as  cross  wind,  and  vary  from  engagement  to  engagement. 
Random  errors  are  those  which  change  from  round  to  round  within  an  engagement  and  are  caused 
by  differences  in  individual  rounds,  wind  gusts,  etc. 

The  first  two  lines  of  each  file  must  contain  a  weapon  name  and  the  number  of  range  increments 
which  will  be  input.  The  range  input  must  account  for  all  ranges  from  0  up  to  and  including  the 
maximum  firing  range  of  the  weapon. 

The  first  section  of  the  file  is  for  a  stationary  firer  against  a  stationary  target.  For  this 
situation  data  is  required  for  the  first  round  fired  and  for  subsequent  rounds.  For  first  rounds,  fixed 
bias,  variable  bias  and  random  error  are  required.  For  subsequent  rounds  only  random  error  is 
needed.  This  error  varies  depending  on  whether  the  previous  shot  was  a  hit,  a  lost  miss,  or  a  sensed 
miss.  Misses  are  either  lost  or  sensed  depending  on  the  value  of  pfsense)  in  the  weapon  description 
file.  For  the  number  of  ranges  to  be  input,  the  user  will  enter  a  range  and  its  corresponding  errors 
for  first  and  subsequent  rounds. 

The  second  section  of  the  file  is  for  a  stationary  firer  against  a  moving  target.  This  section  has 
only  two  types  of  error:  fixed  bias  and  total  error,  which  should  include  the  variable  bias,  add-on, 
and  subtractive  dispersions  for  a  moving  target.  These  errors  are  required  for  four  different  attack 
angles:  0,  30,  60,  and  90  degrees  as  is  shown  in  the  table. 

The  third  section  is  for  a  moving  firer  against  a  stationary  target.  Only  fixed  bias  and  total 
error  are  required  at  each  range. 

The  accuracy  input  for  a  burst-fire  weapon  is  similar  (see  Table  38),  but  with  a  few  differences. 
The  variable  bias  is  input  for  first  burst  and  subsequent  bursts  separately.  There  is  no  input  for 
random  error  based  on  the  result  of  a  previous  round.  And  there  is  no  breakdown  by  attack  angle. 
Also,  for  a  burst-fire  weapon,  if  ranging-in  is  played  (as  specified  in  the  weapon  file),  then  a  ranging-in 
file  must  be  prepared  for  input  (described  later). 
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Table  36:  Accuracy  File:  Non-burst 


♦♦  Comment  Line(s) 

Weapon  Name 
z  remges 

♦  STATIONARY  FIRER  vs  STATIONARY  TARGET 


* 

* 

1st  Round 

h/h 

h/lm 

h/sm 

4c 

fix 

bias 

var  bias 

ran 

err 

ran 

err 

rzm  err 

ran 

err 

* 

rg  (m) 

H 

V 

H  V 

E 

V 

H 

V 

H  V 

E 

V 

rngl 

.  XXX 

.XXX 

.XXX  .XXX 

.XXX 

.  XXX 

.XXX 

.XXX 

. XXX  .XXX 

.XXX 

.XXX 

rngN 

.  XXX 

.XXX 

.XXX  .XXX 

.XXX 

.  XXX 

.XXX 

.XXX 

.XXX  .XXX 

.XXX 

.  XXX 

4c 

* 

* 

* 

4c 

♦ 

♦ 


* 

* 

* 

* 

* 

♦ 


STATIONARY  FIRER  vs  MOVING  TARGET 


0  deg 

fixed  bias  total  error 


rg  (m) 

E 

V 

E 

V 

rngl 

.zxx 

.zxx 

.XXX 

.XXX 

rngN 

.XXX 

.XXX 

.XXX 

.XXX 

fixed 

30  deg 

bias 

total 

error 

rg  (m) 

E 

V 

E 

V 

mgl 

.XXX 

.XXX 

.XXX 

.XXX 

mgS 

.XXX 

.XXX 

.zxx 

.XXX 

*  60  deg 


fixed  bias 

total 

error 

rg  (m) 

E 

V 

E 

V 

rngl 

.XXX 

.XXX 

.XXX 

.XXX 

rngN 

.zxx 

.XXX 

.XXX 

.zxx 

4c 
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Table  37:  Accuracy  File:  Non-burst  -  Continued  (1) 


* 

* 

* 

fixed  bias 

90  deg 

total 

error 

♦ 

rg  (m) 

H 

V 

H 

V 

rngl 

.XXX 

.XXX 

.XXX 

.  XXX 

♦ 

* 

rngN 

.XXX 

MOVING 

.XXX 

FIRER  vs 

STATIONARY 

XXX 

TARGET 

,xxx 

★ 

♦ 

fixed  bias 

total 

error 

♦ 

* 

rg  (m) 

H 

V 

H 

V 

w 

rngl 

.XXX 

.XXX 

XXX 

.  XXX 

rngN 

.XXX 

.XXX 

.  XXX 

.XXX 
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Table  38:  Accuracy  File  (Burst-Fire) 


Comment  Line(s) 

Weapon  Name 

STATIONARY-STATIONARY 

♦ 

X 

ranges 

Vzuriable 

Bias 

* 

fix  bias 

1st  bst 

sub  bsts 

rzm 

err 

♦ 

rg  (m) 

H  V 

H  V 

H  V 

H 

V 

rngl 

.XXX  .XXX 

.XXX  .XXX 

.XXX  .XXX 

.XXX 

.  XXX 

rngN 

.XXX  .XXX 

.XXX  .XXX 

.XXX  .XXX 

.XXX 

.XXX 

♦ 

STATIONARY 

-MOVING 

4c 

4c 

Variable 

Bias 

4c 

fix  bias 

1st  bst 

sub  bsts 

ran 

err 

4c 

rg  (m) 

H  V 

E  V 

H  V 

E 

V 

rngl 

.XXX  .XXX 

.XXX  .XXX 

.XXX  .XXX 

.XXX 

.XXX 

rngN 

.XXX  .XXX 

.XXX  .XXX 

.XXX  ,xxx 

.XXX 

.XXX 

♦ 

4c 

MOVING-STATIONARY 

w 

4c 

Variable 

Bias 

4c 

fix  bias 

1st  bst 

sub  bsts 

ran 

err 

♦ 

* 

rg  (m) 

H  V 

H  V 

H  V 

B 

V 

rngl 

.XXX  .XXX 

.XXX  .XXX 

.XXX  .XXX 

.XXX 

.XXX 

mgN 

.XXX  .XXX 

.XXX  .XXX 

.XXX  .XXX 

.XXX 

.XXX 
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2.7  Vulnerability  Files 


Traditional  vulnerability  calculations  make  use  of  a  mapping  procedure  called  damage  assessment 
lists  (DALs)  or  standard  damage  assessment  lists  (SDALs).  A  DAL  maps  killed  components  and 
sets  of  components  into  Degradation  of  Combat  Utility  (DCU)  or  Loss  of  Function  (LoF)^  typically 
for  Mobility  (M),  Fire^Power  (F),  M  or  F,  and  Catastrophic  Kill  (K).  The  DCU  estimates  developed 
in  the  DAL  process,  defined  as  expected  loss  of  function  values,  are  typically  used  as  if  they  reflected 
probabilities  of  no  capability.  ^  The  DAL  vulnerability  data  required  for  input  to  Groundwars  will 
be  referred  to  as  “probability  of  kill”  in  the  remainder  of  this  report. 

The  vulnerability  files  contain  probability  of  kill  information  which  can  be  entered  as  either 
the  Probability  of  Kill  given  a  Hit  (PKH)  or  as  the  Probability  of  Kill  given  a  Shot  (PKS),  Proba* 
bilities  of  kill  are  generated  by  the  Survivability/Lethality  Analysis  Directorate’s  (SLAD)  Ballistic 
Vulnerability/Lethality  Division  (BVLD)  of  the  Army  Research  Laboratory  (ARL),  formerly  the 
Ballistic  Research  Laboratory  (BRL).  The  names  of  these  files  in  the  current  working  directory  are 
similar  to  those  for  the  accuracy  files.  BLUE  files  have  the  prefix  bpk^  and  RED  files  begin  with 
rpk.  The  BLUE  files  will  be  named:  bpkl,  bpk2,  ...,  bpkJO,  bpklf  ...  PK  files  must  exist  for  every 
combination  of  weapon  system  and  target  vehicle  that  may  engage  one  another.  The  model  checks 
to  see  if  all  combinations  of  weapons  vs.  vehicles  have  been  entered  (including  BLUE  vs.  BLUE 
and  RED  vs.  RED  if  these  combinations  are  specified  in  the  engagement  file).  For  those  that  do 
not  exist,  the  model  will  give  a  warning  message.  The  user  should  check  these  warnings  for  the  first 
runs  of  the  study  to  be  sure  that  no  desired  combination  has  been  missed. 

The  model  recognizes  four  levels  of  kill:  mobility  kill,  fire-power  kill,  mobility  and  fire-power 
kill,  and  catastrophic  kill.  The  four  levels  of  kill  have  the  following  results  in  the  model:  A  mobility 
kill  renders  an  attacker  unable  to  continue  moving;  the  combatant  remains  at  its  current  exposure 
and  range,  and  can  still  engage.  For  a  .defender  or  overwatch  unit,  a  mobility  kill  means  that  it 
may  no  longer  pop  down  to  reload  or  jockey  to  an  alternate  position.  A  fire-power  kill  leaves  the 
combatant  unable  to  fire,  and  it  will  attempt  to  reach  cover  to  avoid  being  killed  further.  For  a 
mobility  and  fire-power  kill,  the  combatant  can  no  longer  function,  but  it  is  not  totally  destroyed. 
Vehicles  which  have  sustained  one  of  these  levels  of  damage  continue  to  draw  fire,  and  may  be  killed 
at  a  higher  level.  A  catastrophically  killed  combatant  no  longer  functions,  and  all  units  know  that 
it  no  longer  is  a  threat. 

The  first  section  of  every  file  contains  the  same  information,  whether  the  user  uses  PKH  or 
PKS.  On  the  first  line  the  weapon  name  and  the  target  vehicle  name  are  given;  these  must  agree 
with  those  input  in  the  unit  deployment  files.  On  the  second  line  two  flags  are  set  which  dictate  the 
form  of  the  vulnerability  data.  PK-Flagl  determines  if  the  data  is  entered  as  PKH  or  PKS  data.  If 
this  flag  is  set  to  a  0  or  a  2  the  data  is  PKS  data.  If  the  flag  is  set  to  1,  the  data  is  PKH.  The  forms 
of  these  data  will  be  described  shortly. 

The  second  flag  on  the  line,  PK-FlagS,  determines  if  the  data  is  independent  of  range  to  the 
target.  For  some  weapons  the  lethality  of  the  weapon  is  the  same  at  all  ranges.  A  “0”  designates 
lethality  which  is  a  function  of  range  and  a  “1”  designates  range  independent  vulnerability. 

The  first  two  forms  of  data  are  probability  of  kill  given  a  shot.  The  data  for  both  forms  are 


2Work  began  in  1988  by  ARL  and  AMSAA  to  develop  improved  vulnerability  metrics,  called  Degraded  States, 
which  overcomes  most  of  the  mathematical  problems  in  the  DAL  process  [J.  Abell,  L.  Roach,  M.  Starks,  DE^ 
GRADED  STATES  VULNERABILITY  ANALYSIS,”  BRL  Technical  Report  BRL-TR-3010,  Jime  1989].  An  exten¬ 
sion  of  Groundwars,  caUed  DSWARS,  was  written  to  use  these  new  metrics  and  has  been  \ised  for  research  purposes 
at  AMSAA  [G.R.Comstock,  “The  Degraded  States  Weapons  Analysis  Research  Simulation  (DSWARS):  An  Investi¬ 
gation  of  the  Degraded  States  Vulnerability  Methodology  in  a  Combat  Simulation,”  AMSAA  Technical  Report  495, 
February  1991]. 
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independent  of  target  aspect  angle  and  round  dispersion.  The  two  forms  require  the  same  data,  but 
are  entered  in  a  different  order.  For  both  forms,  the  data  should  begin  with  range  of  0  meters.  If 
the  first  vulnerability  flag  is  set  to  a  0,  the  data  needs  to  be  in  the  form  shown  in  Table  39.  When 
the  flag  is  set  to  a  2,  the  data  needs  to  be  in  the  form  shown  in  Table  40.  When  PKS  data  is  being 
used,  the  probability  of  hit  is  forced  to  be  1.0  within  the  model,  since  the  probability  of  hit  was 
factored  into  the  calculation  of  the  PKS. 


Table  39:  PKS  Vulnerability  File  (PK-Flagl  =  0) 


**  Comment  LineCs) 

Weapon-Same  Tairget-Vehicle-Same 
0  X  <—  PK-Flags 

♦♦  Om  rng2  mg3  rng4  . . .  rngS  I  Kill  Type  |  Exposure 


X  .  XX 

X  .  XX 

x.xx 

x.xx 

...  x.xx 

1 

M-Kill 

1 

ED 

x.xx 

x.xx 

x.xx 

x.xx 

...  x.xx 

F-Kill 

1 

HD 

X  .XX 

X  .  XX 

x.xx 

x.xx 

H 

H 

w 

1 

MorF-Kill 

1 

HD 

x.xx 

x.xx 

x.xx 

x.xx 

...  x.xx 

1 

K-Kill 

1 

HD 

X  .  XX 

x.xx 

x.xx 

x.xx 

...  x.xx 

1 

M-Kill 

1 

FE 

x.xx 

x.xx 

x.xx 

x.xx 

...  x.xx 

1 

F-Kill 

1 

FE 

x.xx 

x.xx 

x.xx 

x.xx 

...  x.xx 

1 

MorF-Kill 

1 

FE 

x.xx 

x.xx 

x.xx 

x.xx 

...  x.xx 

i 

K-Kill 

1 

FE 

Table  40:  PKS  Vulnerability  File  (PK-Flagl  =  2) 


♦♦  Comment  Line(s) 

Weapon-Name  Target-Vehicle-Name 
2  X  <—  PK-Flags 

♦♦  M  F  MorF  K  I  Range  1  Exposure 

il^i^ntc:^ilf^^i^t************************************** 


x.xx 

x.xx 

x.xx 

x.xx 

1 

0  meters  1 

HD 

x.xx 

x.xx 

H 

M 

H 

x.xx 

1 

range 

2  1 

HD 

x.xx 

x.xx 

x.xx 

x.xx 

1 

range 

3  1 

HD 

x.xx 

x.xx 

x.xx 

x.xx 

1 

1 

range 

4  1 

1 

HD 

x.xx 

x.xx 

x.xx 

x.xx 

1 

1 

range 

N  1 

1 

HD 

x.xx 

x.xx 

H 

H 

H 

x.xx 

1 

1 

0  meters  1 

FE 

x.xx 

x.xx 

X.XX 

M 

M 

M 

1 

range 

2  1 

FE 

x.xx 

M 

H 

H 

M 

H 

H 

H 

M 

H 

1 

range 

3  1 

FE 

x.xx 

x.xx 

X.XX 

X.XX 

1 

1 

range 

4  1 

1 

FE 

x.xx 

x.xx 

x.xx 

X.XX 

1 

1 

range 

N  1 

FE 

The  third  data  format  is  the  Individual  Unit  Action  (lUA)  file  as  produced  by  the  ARL.  For 
this  type  of  input  data,  PK-flagl  should  be  set  to  1.  The  data  is  a  function  of  target,  aspect  angle, 
target  exposure,  round  dispersion  and  kill  criteria.  Table  41  below  shows  the  general  structure  of 


this  file.  This  file  is  formatted,  and  should  be  received  from  the  ARL  in  this  format.  In  certain 
cases,  the  lUA  file  from  ARL  may  contain  a  fifth  kill-type,  creu;.  These  are  not  used  by  Groundwars 
and  should  be  deleted  from  the  file. 

For  each  range  there  is  a  group  of  88  lines  of  PKH  data.  For  vulnerability  which  is  independent 
of  range,  there  will  be  only  one  set  of  88  lines.  In  each  group  of  88  lines  there  are  44  lines  against 
a  hull  defilade  target  followed  by  44  lines  for  fully  exposed  targets.  In  each  group  of  44  lines  there 
are  11  sets  of  4  lines.  The  first  10  sets  of  lines  correspond  to  10  linear  dispersions  (1-10  feet)  and 
the  11th  set  is  for  a  uniform  distribution  of  shots  on  the  target.  Each  of  the  four  lines  corresponds 
to  one  of  the  four  kill  categories. 


Table  41:  lUA  (PKH)  VulnerabUity  File  (PK-Flagl  =  1) 


Comment  Line(s) 

Weapon-Ncune  TetTget-Vehicle-Iaime 
1  X  <—  PK-Flags 

♦  range  E  D  K  0  30  60  90  120  150  180  Avg 


rngl 

1 

1 

1 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngl 

1 

1 

2 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

X  .  XXX 

x.xxx 

x.xxx 

rngl 

1 

1 

3 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngl 

1 

1 

4 

X  .  XXX 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

X  .  XXX 

x.xxx 

x.xxx 

rngl 

1 

2 

1 

X  .  XXX 

x.xxx 

x.xxx 

x.xxx 

X  .  XXX 

x.xxx 

x.xxx 

x.xxx 

rngl 

1 

2 

2 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

X  .  XXX 

X  .  XXX 

x.xxx 

rngl 

1 

2 

3 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

X  .  XXX 

rngl 

1 

2 

4 

x.xxx 

X  .  XXX 

x.xxx 

x.xxx 

x.xxx 

X  .  XXX 

x.xxx 

x.xxx 

rngl 

1 

3 

1 

x.xxx 

X  .  XXX 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngN 

2 

10 

3 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngN 

2 

10 

4 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngN 

2 

11 

1 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngN 

2 

11 

2 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngN 

2 

11 

3 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

rngN 

2 

11 

4 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

x.xxx 

Definitions : 

rngl  -  0  meters 

rngN  -  last  range  for  data 

E  -  Target  Exposure  (1  for  HD,  2  for  FE) 

D  -  Dispersion  of  round  (1  to  10  feet,  11  is  random  dispersion) 

K  -  Kill  Type  (1  is  M-Kill,  2  is  F-Kill,  3  is  MorF-Kill,  4  is  K-Kill) 
Target  Aspect  Angle  -  Angle  of  the  incoming  projectile  flight  path 

measured  from  the  front  of  the  target  in  the 
horizontal  plane  (0  through  180  degrees). 
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2.8  Army  File 


The  army  file  contains  information  that  isn’t  specific  to  any  one  unit  type.  An  army  file  is  required 
for  each  army  in  the  battle.  The  names  of  the  two  files  are  barmy  and  rarmy.  The  general  structure 
of  the  file  is  shown  in  Table  42.  The  army  file  input  variable  definitions  are  listed  in  Tables  43 
through  45. 


Table  42:  Army  File 


Line 

0 

Comment  Line(s) 

1 

— Tactics:  Priority  T(relook)  H(bump) 

T(bump)  Overw-eng 

2 

zx.x 

1C 

XX  .  X  X 

3 

— Communications:  If-comm  P(pass) 

T(pass)  T(search) 

4 

x.xx 

XX 

X  XX  .  X 

5 

— Decoys:  DecKame  H(flash) 

T(start) 

T(llash) 

6 

UNIT  NAME 

X 

XX 

.X 

XX.  X 

7 

— If  Artillery 

8 

X 

9 

Taxgetl 

10 

— Prep.  Artillery 

M 

F 

K&F 

K 

11 

x.xx 

x.xx 

x.xx 

x.xx 

12 

— On-call  Artillery 

M 

F 

M&F 

K 

13 

x.xx 

x.xx 

x.xx 

x.xx 

14 

Target2 

15 

— Prep.  Artillery 

M 

F 

M&F 

K 

16 

x.xx 

x.xx 

x.xx 

x.xx 

17 

— On-call  Artillery 

M 

F 

M&F 

K 

18 

x.xx 

x.xx 

x.xx 

x.xx 

19 

END 
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Table  43:  Army  File  Input  Definitions 


Line 

Variable 

Definition 

2 

Priority 

Target  priority.  If  a  unit  is  able  to  detect  more  than  one  target  concurrently, 
the  firer  will  pick  older  targets  over  new  if  this  is  set  to  1,  and  newer  targets 
over  old  if  this  is  set  to  2.  If  the  unit  cannot  detect  more  than  one  target, 
this  input  will  have  no  effect. 

T(relook) 

The  time  a  firer  will  search  for  other  targets  before  going  back  to  a  pre¬ 
viously  serviced  target  and  renewing  the  engagement  (only  if  the  target  is 
still  in  line  of  sight  and  is  not  k-killed). 

The  next  two  input  variables  are  used  when  a  target  vehicle  is  mobility  &  firepower  killed,  and 

IS  no  longer  functioning.  A  firer  will  recognize  a  target  in  this  condition  as  non-threatening, 
and  will  disengage  it.  The  firer  will  disengage  the  target  after  firing  N(bump)  rounds  at 
it  or  after  waiting  T(bump)  seconds.  When  either  of  these  conditions  is  met,  the  target  is 
dumped  up'’  to  an  unthreatening  vehicle,  and  all  units  will  disengage  it. 

N(bump) 

The  number  of  rounds  fired  before  an  MF-killed  target  is  bumped  up  to  a 
non-threat,  allowing  disengagement. 

T(bump) 

Duration  of  time  (sec)  before  an  MF-killed  target  is  bumped  up  to  a  non¬ 
threat,  allowing  disengagement. 

Overw-eng 

Governs  the  play  of  overwatch  vehicles  for  this  army  in  the  simulation. 

As  described  in  the  unit  deployment  file  section,  overwatch  vehicles  can 
either  fire  as  soon  as  they  acquire  a  target,  or  they  may  stay  quiet  until  the 
enemy  begins  to  fire.  If  the  overwatch  should  fire  upon  acquiring  a  target, 
this  input  is  a  1,  else  it  is  a  0. 

The  next  line  of  input  controls  the  play  of  communications  between  friendly  vehicles. 
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Table  44:  Army  File  Input  Definitions  -  Continued  (1) 


Line 

Variable 

Definition 

4 

If- comm 

When  a  unit  detects  an  enemy  unit,  it  may  pass  the  enemy’s  location  to  other 
units  on  its  side  (e.g.  IVIS  -  Iniervehicular  Informaiion  System).  If  the  location 
is  received,  the  receiver  will  conduct  a  field  of  view  search  in  the  area  and  attempt 
to  acquire  the  target.  Enter  a  1  as  the  value  for  If-comm  to  enable  the  play  of  this 
communication  tactic,  else  enter  0. 

P(pass) 

The  probability  that  the  others  will  receive  the  transmission  of  the  target’s  location. 

T(pass) 

The  time  (sec)  to  wait  before  the  receiving  vehicle  will  conduct  its  search. 

T(search) 

Duration  of  time  (sec)  the  receiving  vehicle  will  search  in  the  field  of  view  before 
renewing  normal  search.  To  have  friendly  units  gang  up  on  the  detected  target,  set 
this  wait  time  to  0.0. 

Decoys:  The  informaiion  necessary  for  ihe  play  of  decoys  is  on  the  next  line.  Decoys  are  entered  as  any 
other  unit  and  vehicle  type  in  ihe  unit  deployment  file.  However^  ihe  weapon  and  sensor  names  should  be 
set  to  “NULV^  When  ihe  army  file  is  read,  ihe  name  of  ihe  decoy  which  is  entered  here  is  used  to  make  all 
units  of  this  type  decoys.  When  only  non-flashing  decoys  are  played,  ihe  remaining  inputs  on  this  line  should 
be  sei  to  0.  When  flashing  decoys  are  played  ihe  user  must  enter  ihe  probability  of  detecting  ihe  flashes  in 
ihe  opposing  sensor  file. 

6 

Dec  Name 

Unit  Name  of  decoy  as  entered  in  the  Unit  Deployment  File. 

N(flash) 

Number  of  flashing  decoys  (subset  of  total  number  of  decoys). 

T(start) 

Time  in  the  battle  (sec)  when  decoys  should  begin  to  flash. 

T(flash) 

Average  time  (sec)  between  decoy  flashes. 
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Table  45:  Army  File  Input  Definitions  -  Continued  (2) 


Line 

Variable 

Definition 

8 

If  Artillery 

Set  to  1  if  artillery  is  to  be  played,  else  0.  Artillery  can  be  preparatory  or 
on-calL  Prep  artillery  is  called  prior  to  the  start  of  battle.  On-call  artillery 
is  delivered  during  the  battle  at  a  random  time.  If  a  0  is  entered  here,  there 
will  be  no  artillery  and  there  are  no  more  entries  in  the  file.  If  the  value 
entered  is  1,  the  following  lines  must  be  input: 

9 

Target  1 

Vehicle  name  of  target 

11 

PrepPKs 

Probability  of  Kill  values  for  prep  artillery  vs  target  1  for  Mobility-only, 

Fire-power  only,  MirF-kill-only,  and  K-kill. 

13 

OnCallPKs 

Probability  of  Kill  values  for  on-call  artillery  vs  targetl  for  Mobility-only, 

Fire-power  only,  MfcF-kill-only,  and  K-kill. 

(Lines  9  through  13  repeated  for  as  many  targets  as  artillery  affects.  If  artillery  is  played,  for  each  enemy 
vehicle  which  is  in  the  intended  target  area,  there  must  be  entered  probabilities  of  kill.  The  names  of  all 
affected  units  must  be  entered.) 

19 

END 

Signifies  no  more  artillery  PKs  to  be  entered. 
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2.9  Obscuration  File 


This  file  defines  changes  in  the  atmospheric  conditions  during  the  battle.  These  changes  affect  all 
combatants  across  the  battlefield.  Smoke  in  the  model  starts  at  a  certain  time,  and  has  a  finite 
duration.  Both  of  these  parameters  are  set  by  the  user.  Any  number  of  smoke  events  can  be  played 
in  the  model,  but  the  more  smoke  events  played  the  slower  the  run  time  will  be  since  all  probabilities 
of  acquisition  and  engagements  are  reassessed  when  the  atmosphere  changes.  This  file  has  the  name 
smkfile.  If  no  smoke  is  desired  in  the  battle,  then  this  file  does  not  need  to  exist.  Table  46  shows 
the  format  of  the  Obscuration  File  and  Table  48  lists  the  input  variable  definitions. 


Table  46:  Obscuration  File 


Line 

0 


♦♦  Comment  Line(s) 


1 

♦*  StZLTt 

duration 

optic 

therm 

radax 

2 

xxxx . 

XXX. 

x.xx 

x.xx 

x.xx 

1st 

smoke 

event 

3 

xxxx. 

XXX. 

x.xx 

x.xx 

x.xx 

2nd 

smoke 

event 

n 

xxxx. 

XXX  . 

x.xx 

x.xx 

x.xx 

nth 

smoke 

event 

Table  47:  Obscuration  File  Input  Definitions 


Line 

Variable 

Definition 

2 

Start 

Battle  time  (sec)  when  1st  smoke  event  starts. 

Duration 

Duration  (sec)  of  this  smoke  event 

Optic 

Attenuation  of  transmission  for  optical  sensors. 

Therm 

Attenuation  of  transmission  for  thermal  sensors. 

Radar 

Attenuation  of  transmission  for  radar  sensors. 

3-n 

continues  for  each  smoke  event 
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2.10  Engagement  Control  File 


Because  Groundwars  can  model  fratricide,  or  friendly  fire  \  a  file  is  needed  to  describe  which  units 
can  engage  one  another.  This  file  also  eliminates  the  need  for  the  simulation  to  calculate  all  of  the 
engagement  interactions  that  would  take  place  between  two  units  which  would  never  realistically 
engage  one  another. 

There  is  only  one  file,  engfile,  which  describes  the  actions  of  both  RED  and  BLUE  units.  If 
fratricide  is  not  desired,  this  file  can  be  ignored,  and  the  model  will  revert  to  a  battle  with  units 
engaging  only  enemy  units;  no  friendly  losses  will  occur.  This  file  is  somewhat  complex  and  the  user 
should  take  care  in  creating  or  modifying  it. 

Engagement  is  governed  in  the  model  by  three  parameters.  The  first  parameter  is  a  yes  or  no 
switch  which  determines  if  the  engaging  unit  might  engage  units  of  each  of  the  other  types.  Given 
that  an  observer,  Aq,  acquires  a  target,  a  check  is  then  made  to  determine  if  is  able  to  identify 
the  target  through  his  sensor  as  either  friendly  or  enemy.  The  input  in  the  sensor  files  governs  the 
ability  of  Aq  to  identify  the  target.  0.6  line  pairs  are  used  as  the  identification  level  criterion.  If 
Ao  is  using  radar,  it  is  assumed  he  cannot  identify  the  target  through  his  sensor.  If  Ao  is  able  to 
identify  the  target  as  friendly,  he  will  break  off  the  engagement.  If  Aq  identifies  it  as  an  enemy,  he 
will  engage  the  target  as  normal.  If  Aq  is  not  able  to  identify  the  target  one  w’ay  or  the  other,  Aq 
must  make  some  decision  whether  he  should  engage  this  “grey”  target.  This  decision  is  characterized 
in  the  model  by  the  last  two  parameters,  the  probability  of  engagement,  and  a  time  delay  associated 
with  the  decision. 

The  engagement  file  contains  a  subsection  for  each  unit  type  in  the  battle.  The  general 
structure  of  a  single  subsection  is  shown  in  Table  48.  The  engagement  file  input  variable  definitions 
are  listed  in  Table  49. 


Table  48:  Engagement  Control  File 


Line 

0 

1 

2 

Comment  Line(s) 

Engaging  Unit's  name 
—  Target  Karnes,  Is-It-A-Tgt, 

P(engage),  T(engage) 

3 

TgtNamel  x 

X . XX  XX . X 

4 

TgtName2  x 

X.XX  XX. X 

n 

TgtNameN  x 

X . XX  XX . X 

n+1 

'END' 

A  sample  engagement  file  is  shown  in  Table  50.  The  first  subsection  is  for  unit  type  BLUEl. 
BLUEl  will  engage  both  BLUE2  and  REDl.  However,  when  he  cannot  identify  a  target  which  he 
has  detected,  he  will  engage  BLUE2  only  40  percent  of  the  time,  but  he  will  engage  REDl  100 
percent  of  the  time.  For  example,  this  could  be  because  REDl  may  be  further  away  or  in  an  area 
where  BLUEl  knows  there  are  no  friendly  units,  and  BLUE2  may  be  in  an  area  where  there  is  a 
good  chance  that  friendly  vehicles  may  be  located.  BLUE2  has  the  location  of  BLUEl  and  will  only 
engage  REDl.  REDl  will  engage  both  BLUE  units,  and  he  will  always  engage  on  detection  since 
his  probabilities  of  engaging  are  1.0. 
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Table  49:  Engagement  File  Input  Definitions 


■ 


Following  this  line,  there  is  a  single  line  entry  for  all  units  which  the  engaging  unit  may  consider  as  a  target. 

34-  TgtNamel  The  engaged  unit’s  name 

Is-It-A-Tgt  1  if  TgtNamel  is  considered  a  potential  tgt  for  EngNamel,  0  if  TgtNamel 
will  not  be  engaged  by  EngNamel 

P(engage)  Probability  of  EngNamel  engaging  TgtNamel  when  EngNamel  is  unable 
to  identify  TgtNamel 

T(engage)  Time  (sec)  for  EngNamel  to  decide  to  engage  TgtNamel  when  unable  to 
identify 

Instead  of  listing  all  of  the  units  in  the  battle,  and  entering  a  0  for  the  ones  not  to  be  engaged,  the  user  may 
enter  only  those  wanted,  and  end  the  subsection  by  entering  END  as  a  unit  name. 


Line 


Variable 

Definition 

EngNamel 

The  engaging  unit’s  name 
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Table  50:  Sample  Engagement  Control  File 


Engagement  Table 

^BLUEl' 

—  Target  Karnes, 

Is-It-A-Tgt, 

P(engage) , 

T(engage) 

^BLUE2^ 

1 

0.4 

5.0 

'REDl^ 

*END^ 

»BLUE2' 

1 

1.0 

o 

o 

—  Target  Haines, 

Is-It-A-Tgt, 

P (engage) , 

T( engage) 

»RED1» 

^END^ 

♦  ♦♦♦ 

'REDl' 

1 

1.0 

5.0 

—  Tairget  Haines, 

Is-It-A-Tgt , 

P( engage). 

T(engage) 

>BLUEr 

1 

1.0 

0.0 

'BLUE2^ 

'EHD' 

1 

1.0 

o 

o 
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2.11  Combat  Identification  File  1  -  Constant  Emitter 


Combat  Identification  Devices  (CID)  provide  a  means  for  an  observer  to  identify  a  target  as  friend 
or  foe  in  order  to  help  prevent  fratricide.  Only  if  the  engagement  file  exists  can  CID  be  played  in 
Groundwars.  Two  ways  of  modeling  a  CID  are  possible  in  the  model.  The  first  type  of  combat 
identification  device  is  one  which  constantly  emits  a  signal  (CIDl).  These  signals  (emitted  by  host 
units)  may  be  detected  by  friendly  units,  and  sometimes  enemy  units.  When  a  host  unit  with  this 
type  of  CID  is  detected  by  a  friendly  observer,  there  is  a  probability  associated  with  the  CID  that 
the  observer  will  then  know  that  the  CID  host  is  friendly.  If  this  probability  is  met,  the  observer  will 
disengage  the  target  (host).  The  CID  signal  being  emitted  can  also  aid  others  in  detecting  the  host 
units.  This  aspect  of  the  CID  is  modelled  as  a  probability  of  detection  in  a  given  time  period.  If  the 
time  period  were  30  seconds,  for  example,  a  random  draw  is  done  every  30  seconds  to  determine  if 
any  of  the  searching  units  will  detect  the  host  because  of  its  signal. 

The  information  to  characterize  these  events  is  entered  in  the  input  file  cidfill.  If  this  file  is  not 
included  in  the  current  working  directory  when  Groundwars  is  run,  then  CIDl  will  not  be  played. 
The  file  contains  a  subsection  for  each  different  unit  type  in  the  battle  which  has  a  CIDl  on  board. 
Table  51  shows  a  single  subsection.  Table  52  lists  CID  File  1  input  variable  definitions. 


Table  51:  Combat  Identification  File  1  -  Structure 


Line 

0 

Comment  Line(s) 

1 

— CID  Host  Name,  Time  tor  Detection  Check 

2 

'BLUEl'  XX. 

3 

—  Probability  of  these  observers  CIDing  host  vehicle 

4 

'BLUE2'  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  ... 

5 

'END' 

6 

—  Probability  of  these  observers  detecting  host  vehicle's  CID  signal 

7 

'BLUE2'  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  ... 

8 

'REDl'  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  ... 

9 

'END' 

Table  53  show^s  an  example  of  a  CIDl  file.  From  the  sample  engagement  file,  there  are  two 
BLUE  unit  types,  BLUEl  and  BLUE2,  and  1  RED  unit  type,  REDl.  The  first  subsection  in 
the  sample  CIDl  file  is  for  BLUEl  as  a  CIDl  host.  The  first  section  shows  that  BLUE2  has  a 
0.99  probability  of  CIDing  BLUEl  at  500  m.  and  that  probability  drops  to  0.20  at  3500  m.  The 
next  section  describes  BLUE2  and  REDl’s  probabilities  of  detecting  BLUEl ’s  CIDl  signal  every  30 
seconds.  So  if  REDl  were  2000  m.  away  from  BLUEl,  REDl  would  have  a  3  percent  chance  of 
detecting  BLUEl  every  30  seconds.  BLUE2  has  a  10  percent  chance  of  detecting  BLUEl  (and  thus 
identifying  BLUEl  as  friendly)  every  30  seconds. 

If  an  observer  from  BLUE2  detects  BLUEl ’s  CIDl  signal,  he  automatically  CIDs  BLUEl  as 
friendly. 

The  second  subsection  in  the  table  shows  the  probabilities  when  BLUE2  has  a  CIDl  type 
system  on  board.  Again  the  probabilities  are  given  for  correct  CID  and  for  detection  of  the  CID 
signal.  There  is  no  subsection  for  REDl  because  REDl  does  not  have  a  CIDl  on  board  in  this 
battle. 
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Table  52;  Combat  Identification  File  1  Input  Definitions 


Line 

Variable 

Definition 

2 

CID  Host  Unit 

Unit  name  of  system  carrying  CID  device 

Det  Check  Time 

Time  (sec)  between  CID  detection  attempts 

4 

ObsCID 

Observer  Unit  Name  (friendly  systems  of  Host  Unit) 

P(CID) 

Probability  (by  range)  of  this  friendly  unit  CIDing  the  host  vehicle 

5 

END 

Ends  this  section 

7 

ObsDet 

■ 

Observer  Unit  Name  (friendly  and  enemy  unit  types  able  to  detect  Host 
Unit  because  of  its  CID  signal) 

P(CDet) 

Probability  (by  range)  of  this  unit  detecting  the  host  vehicle’s  CID  signal. 
These  probabilities  are  based  on  the  time  specified  on  line  2  above. 

9 

END 

Ends  this  section 
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Table  53:  Combat  Identification  File  1  -  Sample 

♦  ♦  Ramges:  500,  1000,  1500,  ... 

— CID  Host  Name,  Time  for  Detection  Check 
'BLUEl'  30. 

—  Probability  of  these  observers  CIDing  host  vehicle 
'BLUE2'  0.99  0.98  0.90  0.80  0.65  0.40  0.20  0.00 
'END' 

—  Probability  of  these  observers  detecting  host  vehicle's  CID  signal 

'BLUE2'  0.50  0.30  0.20  0.10  0.05  0.01  0.00  0.00 

'REDl'  0.30  0.15  0.07  0.03  0.01  0.005  0.00  0.00 

— CID  Host  Name,  Time  for  Detection  Check 
'BLUE2'  30. 

—  Probability  of  these  observers  CIDing  host  vehicle 
'BLUEl'  0.99  0.98  0.90  0.80  0.65  0.40  0.20  0.00 
'END' 

—  Probability  of  these  observers  detecting  host  vehicle's  CID  signal 

'BLUEl'  0.50  0.30  0.20  0.10  0.05  0.01  0.00  0.00 

'REDl'  0.30  0.15  0.07  0.03  0.01  0.005  0.00  0.00 

'END' 
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2.12  Combat  Identification  File  2  -  Query-Response 


The  second  type  of  combat  identification  device  which  can  be  played  is  a  query-response  type  system. 
This  type  of  CID  is  used  after  an  observer  detects  a  target  and  and  before  the  observer  fires  at  it. 
Just  prior  to  firing  at  the  target,  the  firer  queries  the  target,  and  tries  to  elicit  a  response  from  the 
target.  If  the  target  receives  the  signal  and  returns  a  response,  the  firer  will  discontinue  the  firing 
sequence,  disengage  the  target,  and  begin  looking  for  new  targets. 

Associated  with  this  query  and  response  are  four  probabilities  and  a  time  delay.  The  diagram 
below  illustrates  these  inputs.  PI  is  the  probability  that  when  the  host  (observer)  queries  a  target, 
the  signal  will  reach  the  target.  P3  is  the  probability  that  the  target’s  response  will  get  back  to 
the  host  (observer’s)  vehicle.  P2  and  P4  are  the  probabilities  that  the  target  and  then  the  host 
(observer’s)  vehicle  will  correctly  interpret  the  query  and  response,  respectively.  The  time  delay  is 
simply  the  time  from  the  initial  query,  to  the  observer  interpreting  the  response.  What  the  diagram 
does  not  show  is  that  when  the  target  sends  out  its  response,  there  may  be  some  chance  that  the 
response  will  be  detected  by  enemy  units,  which  may  then  engage  that  target. 


Figure  1:  Combat  Identification  Type  2  Methodology 


OBSERVER 


P4  < - P3— 


— >  P2 

TARGET 


The  input  file  for  this  type  of  CID  is  named  cidfil2.  The  file  is  divided  into  a  subsection  for 
each  unit  type  in  the  battle.  The  structure  of  the  subsection  is  shown  in  Table  54.  Table  55  lists 
the  C1D2  file  input  variable  definitions. 

Table  56  shows  a  sample  CID2  file.  BLUEl  has  a  CID2  type  device  on  board  and  will  query 
a  target  one  time  before  engaging  it.  The  time  delay  associated  with  its  CID  varies  from  1.0  second 
at  500  m.  to  1.2  seconds  at  3500  m.,  and  its  probabilities  of  CID  (PI  values)  are  very  high.  BLUEl 
is  only  able  to  CID  BLUE2  since  there  is  no  entry  for  REDl.  BLUEl  is  also  able  to  detect  BLUE2 
when  it  responds  to  a  query.  If  a  firer  from  BLUEl  queries  a  unit  from  BLUE2,  other  observers 
from  BLUEl  have  a  0.1  probability  of  detecting  that  response  at  2000  m. 

The  same  is  true  when  BLUE2  is  the  host  platform.  Its  time  delay  also  ranges  from  1.0  to  1.2 
seconds,  but  it  will  try  to  query  a  target  twice  before  engaging.  Its  probabilities  of  CID  (PI  values) 
are  a  bit  lower  than  BLUEl ’s. 

RED  does  not  have  a  CID  on  board,  but  is  able  to  detect  both  BLUEl  and  BLUE2’s  CID 
responses.  These  probabilities  of  detection  are  entered  in  the  last  section  in  the  table.  For  example, 
when  BLUEl  queries  BLUE2,  REDl  has  a  probability  of  detecting  that  response  of  0.2  at  500  m. 
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Table  54:  Combat  Identification  File  2  -  Structure 


Line 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 


- CID  Host  Unit 

Host  Name 

X  ♦♦♦  Nxmber  of  CID  Attempts 

x.xx  x.xx  x.xx  x.xx  ...  CID  Time  Delay 

x.xx  x.xx  x.xx  x.xx  ...  PI 

-  Probability  of  CID2  Against  These  Targets 

Targetl  Name 


x.xx  x.xx  x.xx 

x.xx 

x.xx  ... 

*** 

P2 

x.xx  x.xx  x.xx 

x.xx 

x.xx  ... 

*** 

P3 

x.xx  x.xx  x.xx 

x.xx 

x.xx  ... 

P4 

Lrget2  Name 

x.xx  x.xx  x.xx 

x.xx 

x.xx  ... 

P2 

x.xx  x.xx  x.xx 

x.xx 

x.xx  ... 

*** 

P3 

x.xx  x.xx  x.xx 

x.xx 

x.xx  ... 

*** 

P4 

^END^ 


- Probability  of  Detecting  These  Teirgets*  Responses 

Targetl  x.xx  x.xx  x.xx  x.xx  x.xx  ...  P(detect) 
'END^ 
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Table  55:  Combat  Identification  File  2  Input  Definitions 


Line 

Variable 

Definition 

2 

CID  Host  Unit 

Unit  name  of  querying  system  carrying  CID  device 

3 

Num  CID  Attempts 

The  number  of  times  this  unit  will  query  a  target  before  engaging  it.  If 
the  firer  receives  a  positive  response  from  any  query  he  will  disengage  the 
target,  and  not  query  again.  If  this  unit  has  no  CID  then  the  input  is  0. 

4 

CID  Time  Delay 

The  time  from  the  initial  query  to  the  observer  interpreting  the  response 
(by  range). 

PI 

The  probabilities  that  when  the  host  queries  a  target,  the  signal  will  reach 
the  target  (by  range). 

Next  there  is  a  subsection  for  each  unit  type  to  be  queried  by  the  CID.  Within  each  subsection  the  user  enters 
the  target  unit's  name,  and  P2,  P3,  and  P4-  The  section  must  he  ended  with  an  'END'  as  the  target  name. 

7 

QTarget.Name 

Unit  name  of  system  type  to  be  queried  by  the  CID. 

8 

P2 

The  probabilities  that  the  target  will  correctly  interpret  the  query  (by 
range). 

9 

P3 

The  probability  that  the  target’s  response  will  get  back  to  the  host  vehicle 
(by  range). 

10 

P4 

The  probabilities  that  the  host  wdll  correctly  interpret  the  response  (by 
range). 

The  Iasi  secUon  defines  ihe  chance  for  ihe  host  vehicle  to  detect  a  target  when  it  responds  to  a  CID2  query. 

17 

RTcirget  Name 

Unit  name  of  system  type  which  responds  to  a  CID2  query. 

P(Cdetect) 

Probabilities  that  the  host  vehicle  will  detect  RTarget  w'hen  it  responds  to 
a  CID2  query  (by  range). 
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Table  56:  Combat  Identification  File  2  -  Sample 


♦**  Comment  Line(s) 

BLUEl 

1 

♦♦*  lumber  of  CID  Attempts 

1.0  1.0  1.0  1.1  1.1  1.1  1.2 

♦**  CID  Time  Delay 

1.0  1.0  1.0  1.0  1.0  1.0  0.85 

♦**  PI 

-  Probability  of  CID2  Against  These  Targets 

BLUE2 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

***  P2 

1.0  1.0  1.0  1.0  1.0  1.0  0.85 

P3 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

**♦  P4 

>END' 

-  Probability  Detecting  These  Targets 

Responses 

BLUE2  0.2  0.2  0.2  0.1  0.1  0.0  0.0 

***  P(detect) 

^END^ 

***  Comment  Line(s) 

BLUE2 

2 

***  Number  of  CID  Attempts 

1,0  1.0  1.0  1.1  1.1  1.1  1.2 

***  CID  Time  Delay 

0.5  0.5  0.3  0.3  0.2  0.1  0.0 

***  PI 

-  Probability  of  CID2  Against  These  Targets 

BLUEl 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

*♦*  P2 

1.0  1.0  1.0  1.0  1.0  1.0  0.85 

P3 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

•**  P4 

'END* 

-  Probability  Detecting  These  Targets^ 

Responses 

'END' 

Comment  Line(s) 

REDl 

0 

♦**  Number  of  CID  Attempts 

7*0.0 

***  CID  Time  Delay 

7*0.0 

PI 

-  Probability  of  CID2  Against  These  Targets 

'END' 

-  Probability  Detecting  These  Targets^ 

Responses 

BLUEl  1.0  1.0  1.0  1.0  1.0  1.0  1.0 

♦**  P(detect) 

BLUE2  0.2  0.2  0.2  0.1  0.1  0.0  0.0 

♦**  P(detect) 

'END' 
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2.13  Range-In  File 


Ranging-tn  is  a  process  used  by  gunners  to  adjust  fire  on  the  target.  The  range-in  process  lowers 
accuracy  errors  for  weapon  systems  wdth  limited  fire  control,  since  the  gunner  must  correct  for  errors 
associated  with  target  range  estimation,  system  biases,  etc.  The  gunner  achieves  more  accurate  fire 
by  adjusting  the  aimpoint  in  response  to  the  perceived  impact  location  of  the  preceding  round.  If  the 
range-in  variable  is  set  to  True  (T)  in  the  Weapon  Description  Input  File,  then  this  Ranging-In  file 
must  be  input.  Range-in  files  are  named  brng?  or  rmg?  for  Blue  and  Red  systems  respectively.  The 
indicates  sequential  numbers  from  1  to  the  number  of  weapons  using  range-in.  For  example,  if 
the  Blue  force  has  4  weapon  systems,  3  of  which  are  playing  range-in,  the  model  will  look  for  brngl, 
brngS,  and  bmgS. 

When  a  firer  is  ranging- in,  the  model  does  not  use  the  accuracy  file  and  vulnerability  fire  input 
for  calculating  whether  the  target  is  hit,  and  for  assessing  damage.  Instead,  it  uses  the  Range-In  file 
input  to  determine  how  many  bursts  need  to  be  fired  before  ranging-in  to  the  target.  The  model 
will  schedule  the  firer  to  fire  that  many  bursts,  and  use  the  probability  of  kill  values  in  the  Range-In 
file  to  assess  the  damage  on  the  last  range-in  round.  If  the  target  is  not  killed,  the  firer  will  then 
continue  to  engage  the  target,  with  the  normal  accuracy  file  and  vulnerability  file  input  then  used 
as  normal. 

Table  57  shows  the  structure  for  the  Range-In  file.  The  Range-In  File  input  variable  definitions 
are  listed  in  Table  58. 
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Table  57 :  Range* In  Input  File 


Line 

1 

'BLUEl^ 

2 

*  SubFir, 

Hin  Reinge, 

Majc  attempts 

3 

z.x 

xxxx.x 

XX 

4 

♦ 

STATIOMARY-STATIOIARY 

5 

*  Rng  1 

2  3 

4 

5  6 

7 

8  9  10 

6 

rngl  z.x 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

7 

rng2  X . X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

8 

mgS  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

9 

mg4  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

10 

rngS  X . X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

11 

STATIONARY-MOVIKG 

12 

*  Rng  1 

2  3 

4 

5  6 

7 

8  9  10 

13 

rngl  x.x 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

14 

rng2  X .  X 

x.x  x.x 

z.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

15 

rng3  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

16 

rng4  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

17 

rngS  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

18 

* 

MDVING-STATIOHARY 

19 

*  Rng  1 

2  3 

4 

5  6 

7 

8  9  10 

20 

rngl  x.x 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

21 

rng2  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

• 

22 

rng3  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

23 

rng4  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

24 

rngS  X .  X 

x.x  x.x 

x.x 

x.x  x.x 

x.x 

x.x  x.x  x.x 

25 

♦ 

26 

♦  PK^s  lor 

linal  range-in 

round 

27 

♦  HD 

FE 

28 

*  Mkill  Fkill 

MFkill  Kkill 

Mkill 

Fkill  MFkill 

Kkill 

29 

*RED1' 

30 

0  X . XX  X . XX 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

31 

rng2  X . XX  x . xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

32 

rng3  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

33 

rng4  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

34 

rngS  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

35 

rng6  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

36 

♦ 

37 

*  PR's  lor 

linal  range-in  round 

38 

♦  HD 

FE 

39 

♦  Mkill  Fkill 

MFkill  Kkill 

Mkill 

Fkill  MFkill 

Kkill 

40 

♦RED2' 

41 

H 

M 

M 

H 

H 

H 

O 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

42 

mg2  X.XX  X.XX 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

43 

rng3  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

44 

mg4  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

45 

rngS  x.xx  x.xx 

x.xx 

x.xx 

x.xx 

x.xx  x.xx 

x.xx 

46 

rng6  x.xx  x.xx 

x.xx 

X  .  XX 

x.xx 

x.xx  x.xx 

x.xx 

47 

.  * 
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Table  58;  Range- In  File  Input  Definitions 


Line 

Variable 

Definition 

1 

Weapon  Name 

Weapon  name  of  system.  Must  match  weapon  name  used  in  the  Unit  Input 

File. 

3 

SubFir 

Subsequent  firing  time  (sec)  for  range-in  attempts. 

Min  Range 

Minimum  range  (m)  at  which  ranging-in  is  needed. 

Max  attempts 

Maximum  number  of  range-in  attempts  in  an  engagement. 

Next  are  input  three  sets  of  range-in  probability  tables,  for  the  firer-target  combinations  of  stationary- 
stationary,  stationary-moving,  and  moving- stationary. 
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Table  59:  Range-In  File  Input  Definitions  -  Continued  (1) 


Line 

Variable 

Definition 

6-10 

Range 

Stationary  Firer  -  Stationary  Target  Conditions.  Range  (m)  from  firer  to 
target.  The  first  range  should  be  the  value  of  the  range  increment  input 
in  the  Game  File.  The  last  range  should  be  equal  to  or  greater  than  the 
maximum  firing  range  of  the  weapon. 

P(rgin) 

Probability  of  ranging-in  using  one  round,  two  rounds,  three  rounds,  ...» 
ten  rounds.  The  probability  of  ranging-in  for  the  maximum  range-in  rounds 
must  be  equal  to  1.0  as  for  each  range  they  are  cumulative  probability 
distributions.  During  the  game,  a  random  number  is  drawn  and  the  table 
is  accessed  to  determine  the  number  of  range-in  rounds  needed.  The  last 
range-in  round  will  “hit”  the  target  and  the  impact  is  assessed  using  the 

Range-In  PKH  tables  (see  description  of  lines  29-35).  In  reality,  the  last 
range-in  round  wull  impact  within  a  close  enough  distance  to  the  target  to 
cause  the  gunner  to  decide  to  start  firing  for  effect.  Thus,  the  last  round 
does  not  always  hit  the  target,  but  it  might. 

13-17 

Stationary  Firer  -  Moving  Target  Conditions,  (as  for  6-10) 

20-24 

Moving  Firer  -  Stationary  Target  Conditions,  (as  for  6-10) 

Nexif  for  each  target  type  is  input  a  PKH  table  to  he  used  for  the  last  range-in  round.  The  PKs  are  entered 
as  a  function  of  lUA  kill  type,  target  exposure,  and  range. 

29 

Vehicle  Name 

Vehicle  name  of  target. 

30-35 

Range 

Range  (m)  from  firer  to  target  (for  Range-In  PKH  files).  The  first  range 
should  be  zero.  Increments  must  be  as  set  in  the  game  file.  The  last  range 
should  be  equal  to  or  greater  than  the  maximum  firing  range  of  the  weapon. 

RI-PKH 

_ 

Range-in  PKH  values  for  M-kill,  F-kill,  MorF-kill,  and  K-kill.  The  first 
group  of  four  are  versus  a  hull  defilade  target,  the  second  four  are  versus 
a  fully  exposed  target.  These  values  will  be  converted  to  M-only,  F-only, 

M&F,  K-kill,  and  nokill  for  Groundwars’  use. 
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3  Release  Authority 


The  Groundwars  Model  is  the  property  of  the  Federal  Government.  The  model  may  be  released  to 
any  government  agency  which  has  a  use  for  it.  However,  release  to  a  government  agency  does  not 
give  authority  for  that  agency  to  release  the  model  to  other  agencies  or  contractors. 

Contractors  are  permitted  use  of  the  model  if  a  contract  exists  with  the  government  which 
requires  its  use.  Contractors  are  required  to  have  their  government  point  of  contact  provide  this 
office  with  a  letter  of  request.  Upon  receipt  of  this  request,  AMSAA  will  provide  the  contractor  with 
a  Memorandum  of  Agreement  for  the  use  and  modification  of  the  model.  Upon  execution  of  this 
agreement,  AMSAA  will  provide  the  model  to  the  government  POC,  who  in  turn  provides  it  to  the 
contractor. 

Any  modifications  which  are  made  to  the  model  should  be  provided  to  this  office.  Any  errors 
in  the  model  should  be  addressed  to  one  of  the  points  of  contact  in  the  next  section.  Requests  for 
the  model  should  be  sent  to: 


Director 

US  Army  Materiel  Systems  Analysis  Activity 
ATTN:  AMXSY>CD^(L.  Harrington) 
Aberdeen  Proving  Ground,  MD  21005-5071 


4  Points  of  Contact 


The  following  list  provides  points  or  places  of  contact  for  questions  pertaining  to  the  Groundwars 
Model  and  required  input  data. 


•  Groundwars  Model: 

Gary  Comstock  (DSN  298-4090) 
Lilly  Harrington  (DSN  298-5373) 
Simulation  Branch  (AMXSY-CD), 
Combat  Integration  Division, 
AMSAA 


•  Vulnerability  Data: 

Ballistic  Vulnerability/Lethality  Division  (BVLD) 
Survivability/Lethality  Analysis  Directorate  (SLAD) 
Army  Research  Laboratory  (ARL) 

Aberdeen  Proving  Ground,  MD 
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•  Terrain  Data: 

Danny  Champion  (DSN  258-5891), 
TRAC, 

White  Sands  Missile  Range,  NM 


•  Firing  Cycle  Times,  Delivery  Accuracy: 

Jesse  Brewer  (DSN  298-3374), 
Armor  Branch 
Combat  Evaluation  Division 
AMSAA 

R.  Scungio  (DSN  298-2447), 
Infantry  Branch 
Combat  Evaluation  Division 
AMSAA 


•  Target  Acquisition: 

Jeff  Matthews  (DSN  298-6616) 
C4I  Branch 

Combat  Integration  Division, 
AMSAA 


(Commercial  phone  prefix  for  AMSAA  and  ARL  is  (410)-278-XXXX) 
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5  Distribution  List 


Copies  Organization 
4  Director 

US  Army  Armament  RDAE  Center 
ATTN:  SMCAR-FSS-E  (J.  Brooks) 
SMCAR-FSS-E  (A.  Rahe) 
SMCAR-FSF-B  (R.Gullifer) 
SMCAR-FS-A(l)  (R.  Collett) 
Picatinny  Arsenal, HJ  07806-5000 


2  Commander 

US  Army  Survivability 
Management  Office 
ATTN:  SLCSM-SE  (B.  King) 

2800  Powder  Mill  Road 
Adelphi,  MD  20783-1145 

7  Commander 

Defense  Technical  Information 
Center 

ATTN:  DTIC-FDAC 
Cameron  Station,  Bldg  5 
Alexandria,  VA  22304-6145 


1  Director 

US  Army  Vulnerability  Assessment 
Office 

ATTN:  SLCVA  (D.  Mathews) 

White  Sands  Missile  Range,  NM 
88002-5513 


5  Commander 

US  Army  Missile  Command 
ATTN:  AMSMI-OR-SA  (N.  Powell) 
(J.  Smith) 

AMSMI-RD-SM  (H.  Barber) 
AMSMI-RD-SS 
AMSMI-SW  (C.  George) 
Redstone  Arsenal, AL  35898-5060 


1  Commander 

US  Army  Armor  Center 
ATTK:  ATZK-CDC  (L.  Vowels) 
Fort  Knox,  KY  40121-5212 
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Copies  Organization 


3  Commander 

US  Army  Tank  Automotive  Command 
ATTN:  AMSTA-VSA  (M.  Kerr) 

AMSTA-RSC  (B.  Boydoin) 
AMSTA-CMB-T  (C.  Karras) 
Warren,  MI  48397-5000 

1  Commander 

US  Army  Communications -Electronics 
Command  at  Ft .  Monmouth 
ATTN:  AMSEL-RD-EW-C  (J.  Hardy) 

Fort  Monmouth,  NJ  07703-5000 


1  Commemder 

Night  Vision  Electronic  Sensors  Directorate 
ATTN:  AMSEL-RD-NV-GSD  (J.  England) 

Fort  Belvior,  VA  22060-5677 

1  Commander 

US  Army  Natick  ReseaLTch  Development 
and  Engineering  Center 
ATTN:  STRNC-AC  (J.  O^Keefe) 

Natick.  MA  01760-5000 

3  Program  Executive  Office 

Armored  Systems  Modernization 
ATTN:  SFAE-ASM-SS-P  (D.  Bjoraker) 

(L.  Jokubaitis) 

Warren,  MI  48397-5000 


1  HQDA 

ATTN:  SAUS-OR  (LtC.  Hardy) 
Pentagon,  Room  1E643 
Washington,  DC  20310-0102 


2  HQDA 

ATTN:  SARD-DO  (Col.  Bigelman) 
(Maj .  Decker) 
Washington,  DC  20310-0102 


1  Analysis  and  Simulation,  Inc. 
ATTN:  P.  Patti 

172  Holtz  Road,  One  American  Park 
Buffalo,  NY  14225 
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Copies  Organization 


1  Dynetics,  Inc. 

P.D.  Drawer  B 
ATTN:  T.  Gil 

Huntsville,  AL  35814-5050 


1  General  Dynamics  Land  Systems,  Inc. 
ATTN:  J.  Keyes 
P.O.  Box  2074 
Warren,  MI  48090-2074 
Mail  Zone  436-21-19 


1  Hercules  Defense  Electronics 
Systems,  Inc. 

ATTN:  J.  Harrison 
P.O.  Box  4648 
Clearwater,  FL  34618 


1  Kaman  Sciences  Corporation 
ATTN:  L.  Owen 
P.O.  Box  7463 

Colorado  Springs,  CO  80933-7463 

1  Nomura  Enterprises,  Inc. 

ATTN:  J.  Manna 
2832  Fifth  Street 
Rock  Island,  IL  61201 


1  SURVIAC  Satellite  Office 
ATTN:  M.  McGinnis 
Ste.  1610 

1300  North  Seventeenth  Street 
Rosslyn,  VA  22209 

1  Commander 

U.S.  Army  Field  Artillery  School 
ATTN:  ATSF-CCB  (R.  Lillard) 

Fort  Sill,  OK  73503-5600 
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Copies  Organization 


Aberdeen  Proving  Ground 
1  Director 

Army  Research  Laboratory 
ATTN:  SLCBR-SE  (F.  Bunn) 

41  Director 

US  Army  Materiel  Systems  Analysis  Activity 
ATTN:  AMXSY-CD  (Wilbert  Brooks) 

(Brad  Bradley) 

(Gary  Comstock) 

(Lilly  Harrington) 

(Tom  Ruth) 

(Rich  Sandmeyer) 

(Mike  Schmidt) 

(Floyd  Wofford) 

(Bill  Yeakel) 

(Don  Hodge) 

20  extra 

AMXSY-EA  (Jesse  Brewer) 

(Ed  Christman) 

(Paul  Crise) 

(Tom  DeFrank) 

(Mike  Dewitz) 

(Lisa  Karagulian) 

(Lawrence  Kravitz) 

(George  Malouf) 

(Bryan  Pauris) 

(MAJ  Pride) 

(Barry  Siegel) 

(Joe  Valentine) 

(Alex  Wong) 

AMXSY-CA  (Richard  Mezan) 

(Mike  Ray) 

AMXSY-EI  (Julian  Chernick) 

(Jeff  Corley) 

(Rich  Scungio) 

(Ron  Thompson) 

AMXSY-PA  (RPC,  3cys) 
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AMXSY-CD 


GIST 


SUBJECT:  Technical  Report  xxx,  Groundwars  5.3  User's  Guide 
PRINCIPAL  FINDINGS:  NA 
MAIN  ASSUMPTIONS:  NA 
PRINCIPAL  LIMITATIONS:  NA 

SCOPE  OF  THE  EFFORT:  Groundwars  Combat  Simulation.  Ground  to  ground 
combat  simulation  of  a  two-sided  battle  between  heterogeneous  forces. 

OBJECTIVE:  To  document  the  input  requirements  of  the  model  and  to 

inform  the  user  of  the  requirements  and  capabilities  of  the  model. 

BASIC  APPROACH:  The  simulation  is  based  on  Monte  Carlo  probability 
theory.  It  is  event-sequenced  with  critical  ground  battle  events  being 
modeled . 

REASON  FOR  PEPJFORMING  THE  EFFORT:  To  document  the  input  requirements 
of  the  model  for  user  execution. 

IMPACT  OF  THE  EFFORT:  NA 

SPONSOR:  U.S.  Army  Materiel  Systems  Analysis  Activity 

PRINCIPAL  IN">/ESTIGATOR:  Gary  R.  Com.stock 

COMMENTS  AND  QUESTIONS: 

AMXSY-CD  (Attn:  G.  Comstock) 

Aberdeen  proving  Ground,  MD  21005-5071 
DSN  298-4090,  COM  410-278-4090 

DEFENSE  TECHNICAL  INFORMATION  CENTER  (DTIC)  ACCESSION  NUMBER  OF  FINAL 
REPORT:  Report  available  by  contacting  AMSAA' s  Reports  Processing  Center, 
DSN  298-5676 

NHO  COULD  BENEFIT  FROM  THIS  REPORT:  Within-house  and  outside  government 
agencies  who  use  the  Groundwars  model  to  conduct  weapon  system  analyses. 
Also,  defense  contractors  who  use  the  model  need  this  report  to  format 
input  data. 


